linux-stable.git/net/netfilter, branch v7.1.6

ipvs: reload ip header after head reallocation

2026-07-24T14:21:22+00:00

commit a2f57827bf7c695b8c72dc4511cae8e86582369d upstream.

__ip_vs_get_out_rt() calls skb_ensure_writable() which may
reallocate skb->head.

Fixes: 8d8e20e2d7bb ("ipvs: Decrement ttl")
Cc: stable@vger.kernel.org
Assisted-by: Claude:claude-sonnet-4-6
Acked-by: Julian Anastasov 
Signed-off-by: Florian Westphal 
Signed-off-by: Greg Kroah-Hartman

ipvs: fix more places with wrong ipv6 transport offsets

2026-07-24T14:21:22+00:00

commit b3fe4cbd583895987935a9bdad01c8f9d3a02310 upstream.

Sashiko reports for more incorrect IPv6 transport offsets.

The app code for TCP was assuming IPv4 network header
even after the ipvsh argument was provided. This can
cause problems with apps over IPv6. As for the only
official app in the kernel tree (FTP) this problem is
harmless because we use Netfilter to mangle the FTP
ports and we do not adjust the TCP seq numbers.

Also, provide correct offset of the ICMPV6 header in
ip_vs_out_icmp_v6() for correct checksum checks when
the IPv6 packet has extension headers.

Fixes: d12e12299a69 ("ipvs: add ipv6 support to ftp")
Fixes: 2a3b791e6e11 ("IPVS: Add/adjust Netfilter hook functions and helpers for v6")
Cc: stable@vger.kernel.org
Link: https://sashiko.dev/#/patchset/20260706101624.69471-1-zhaoyz24%40mails.tsinghua.edu.cn
Signed-off-by: Julian Anastasov 
Signed-off-by: Florian Westphal 
Signed-off-by: Greg Kroah-Hartman

ipvs: reset full ip_vs_seq structs in ip_vs_conn_new

2026-07-24T14:21:19+00:00

commit 2975324d164c552b028632f107b567302863b7f6 upstream.

Commit 9a05475cebdd ("ipvs: avoid kmem_cache_zalloc in
ip_vs_conn_new") changed ip_vs_conn_new() to allocate an ip_vs_conn
object with kmem_cache_alloc().  The function then initializes many
fields explicitly, but only resets in_seq.delta and out_seq.delta in the
two struct ip_vs_seq members.

That leaves init_seq and previous_delta uninitialized.  This is normally
harmless while the corresponding IP_VS_CONN_F_IN_SEQ or
IP_VS_CONN_F_OUT_SEQ flag is clear.  For connections learned from a sync
message, however, ip_vs_proc_conn() preserves those flags from
IP_VS_CONN_F_BACKUP_MASK and passes opt=NULL when the message omits
IPVS_OPT_SEQ_DATA.  In that case the new connection can be hashed with
SEQ flags set but with the rest of in_seq/out_seq still containing stale
slab data.

When a packet for such a connection is later handled by an IPVS
application helper, vs_fix_seq() and vs_fix_ack_seq() use
previous_delta and init_seq to rewrite TCP sequence numbers.  A malformed
sync message can therefore make forwarded packets carry stale slab bytes
in their TCP seq/ack numbers, and can also corrupt the forwarded TCP
flow.

Reset both struct ip_vs_seq members completely before publishing the
connection.  This matches the existing "reset struct ip_vs_seq" comment
and keeps the sequence-adjustment gates inactive unless valid sequence
data is installed later.

Fixes: 9a05475cebdd ("ipvs: avoid kmem_cache_zalloc in ip_vs_conn_new")
Cc: stable@vger.kernel.org
Reported-by: Yizhou Zhao 
Reported-by: Yuxiang Yang 
Reported-by: Ao Wang 
Reported-by: Xuewei Feng 
Reported-by: Qi Li 
Reported-by: Ke Xu 
Assisted-by: Claude-Code:GLM-5.2
Signed-off-by: Yizhou Zhao 
Signed-off-by: Florian Westphal 
Signed-off-by: Greg Kroah-Hartman

ipvs: use parsed transport offset in SCTP state lookup

2026-07-24T14:21:19+00:00

commit 2f75c0faa3361b28e36cc0512b3299e163e25789 upstream.

set_sctp_state() reads the SCTP chunk header again in order to drive the
IPVS SCTP state table. For IPv6 it computes the offset with
sizeof(struct ipv6hdr), while the surrounding IPVS code uses iph.len from
ip_vs_fill_iph_skb(), where ipv6_find_hdr() has already skipped
extension headers and found the real transport header.

This makes the state machine read from the wrong offset for IPv6 SCTP
packets that carry extension headers. For example, an INIT packet with an
8-byte destination options header can be scheduled correctly by
sctp_conn_schedule(), but set_sctp_state() reads the first byte of the
SCTP verification tag as a DATA chunk type. The connection then moves
from NONE to ESTABLISHED instead of INIT1, gets the longer established
timeout, and updates the active/inactive destination counters
incorrectly. This happens even though the SCTP handshake has not
completed.

Use the parsed transport offset passed down from ip_vs_set_state() for
the SCTP chunk-header lookup. For IPv4 and IPv6 packets without
extension headers this preserves the existing offset.

Fixes: 2906f66a5682 ("ipvs: SCTP Trasport Loadbalancing Support")
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/netdev/20260705123040.35755-1-zhaoyz24@mails.tsinghua.edu.cn/
Reported-by: Yizhou Zhao 
Reported-by: Yuxiang Yang 
Reported-by: Ao Wang 
Reported-by: Xuewei Feng 
Reported-by: Qi Li 
Reported-by: Ke Xu 
Assisted-by: Claude Code:GLM-5.2
Signed-off-by: Yizhou Zhao 
Acked-by: Julian Anastasov 
Signed-off-by: Florian Westphal 
Signed-off-by: Greg Kroah-Hartman

netfilter: nfnetlink_cthelper: cap to maximum number of expectation per master on updates

2026-07-24T14:21:16+00:00

commit 278296b69fae5dd951599692cd481bae4995215c upstream.

Really cap it to NF_CT_EXPECT_MAX_CNT (255) on updates.

The commit ("netfilter: nfnetlink_cthelper: cap to maximum number of
expectation per master") only covers creation of helpers, not updates.

Fixes: 397c8300972f ("netfilter: nf_conntrack_helper: cap maximum number of expectation at helper registration")
Signed-off-by: Pablo Neira Ayuso 
Signed-off-by: Florian Westphal 
Signed-off-by: Greg Kroah-Hartman

netfilter: nfnetlink_cthelper: cap to maximum number of expectation per master

2026-07-24T14:21:16+00:00

commit bf5355cfdede3e30b30e63a5a74f6bdaafb26082 upstream.

If userspace helper policy updates sets maximum number of expectation to
zero, cap it to NF_CT_EXPECT_MAX_CNT (255) on updates too.

Fixes: 397c8300972f ("netfilter: nf_conntrack_helper: cap maximum number of expectation at helper registration")
Signed-off-by: Pablo Neira Ayuso 
Signed-off-by: Florian Westphal 
Signed-off-by: Greg Kroah-Hartman

netfilter: flowtable: use correct direction to set up tunnel route

2026-07-24T14:20:54+00:00

commit 90941d9c925d66a482c9121919ec3546a6988c16 upstream.

The layer 2 encapsulation and layer 3 tunnel information in the xmit
path is taken from the other tuple, because the tunnel information that
is included in the tuple for hashtable lookups is also used to perform
the egress encapsulation in the transmit path.

This patch uses the correct direction when setting up the tunnel, the
original proposed patch to address this fix uses the reversed direction.

While at it, remove the redundant check to call dst_release() to drop
the reference on the dst that was obtained from the forward path, which
is not useful in the direct xmit path unless tunneling is performed.

Fixes: fa7395c02d95 ("netfilter: flowtable: support IPIP tunnel with direct xmit")
Cc: stable@vger.kernel.org
Signed-off-by: Pablo Neira Ayuso 
Signed-off-by: Florian Westphal 
Signed-off-by: Greg Kroah-Hartman

netfilter: xt_nat: reject unsupported target families

2026-07-24T14:20:54+00:00

commit 5d1a2240935ea47e2673d0ea17fdb058e4dc91dd upstream.

xt_nat SNAT and DNAT target handlers assume IP-family conntrack state
is present and can dereference a NULL pointer when instantiated from an
unsupported family through nft_compat. A bridge-family compat rule can
therefore trigger a NULL-dereference in nf_nat_setup_info().

Reject non-IP families in xt_nat_checkentry() so unsupported targets
cannot be installed. Keep NFPROTO_INET allowed for valid inet NAT
compat users and leave the runtime fast path unchanged.

[ The crash was fixed via
  9dbba7e694ec ("netfilter: nft_compat: ebtables emulation must reject non-bridge targets"),
  so this patch is no longer critical.
  Nevertheless, NAT is only relevant for ipv4/ipv6, so this extra
  family check is a good idea in any case. ]

Fixes: c7232c9979cb ("netfilter: add protocol independent NAT core")
Cc: stable@vger.kernel.org
Reported-by: Yuan Tan 
Reported-by: Yifan Wu 
Reported-by: Juefei Pu 
Reported-by: Zhengchuan Liang 
Reported-by: Xin Liu 
Assisted-by: Codex:GPT-5.4
Signed-off-by: Wyatt Feng 
Signed-off-by: Ren Wei 
Signed-off-by: Florian Westphal 
Signed-off-by: Greg Kroah-Hartman

netfilter: ecache: fix inverted time_after() check

2026-07-24T14:20:54+00:00

commit b06163ce52ec0561f202fbfb9b08090cb61f512e upstream.

ecache_work_evict_list() redelivers DESTROY events for conntracks that
were moved to the per-netns dying_list after event delivery failed.  It
sets a 10ms deadline:

    stop = jiffies + ECACHE_MAX_JIFFIES

but then tests:

    time_after(stop, jiffies)

This condition is true while the deadline is still in the future, so the
worker returns STATE_RESTART after the first successful redelivery in the
usual case.  ecache_work() maps STATE_RESTART to delay 0, which turns the
redelivery path into one dying conntrack per workqueue dispatch and makes
the sent > 16 batching/cond_resched() path effectively unreachable.

A conntrack netlink listener whose receive queue is congested can make
DESTROY event delivery fail with -ENOBUFS.  With sustained conntrack
churn, entries then accumulate on the dying_list and are only drained at
the degraded one-entry-per-dispatch rate once delivery succeeds again,
wasting CPU on back-to-back workqueue reschedules and prolonging
conntrack memory/resource pressure.

In a KASAN QEMU test with CONFIG_NF_CONNTRACK_EVENTS=y and
nf_conntrack.enable_hooks=1, a congested DESTROY listener caused 8192
nf_ct_delete() calls to return false and move entries to the dying_list.
After closing the listener, the unfixed kernel needed 7670 ecache_work()
entries to destroy 7669 conntracks.  With this change, the same 8192
entries were destroyed by 2 ecache_work() entries.

Swap the comparison so the worker restarts only after the deadline has
expired.

Fixes: 2ed3bf188b33 ("netfilter: ecache: use dedicated list for event redelivery")
Cc: stable@vger.kernel.org
Reported-by: Yizhou Zhao 
Reported-by: Yuxiang Yang 
Reported-by: Ao Wang 
Reported-by: Xuewei Feng 
Reported-by: Qi Li 
Reported-by: Ke Xu 
Assisted-by: Claude-Code:GLM-5.2
Signed-off-by: Yizhou Zhao 
Signed-off-by: Florian Westphal 
Signed-off-by: Greg Kroah-Hartman

netfilter: xt_physdev: masks are not c-strings

2026-07-24T14:20:54+00:00

commit f468c48d488d0ea2df3422b3e1dfafae1611e853 upstream.

... and must not be subjected to the 'nul terminated' constraint.
If the interface name is 15 characters long, the mask is 16-bytes
'0xff' (to cover for \0) and the valid device name is rejected.

Fixes: 8df772afc9d0 ("netfilter: x_physdev: reject empty or not-nul terminated device names")
Cc: stable@vger.kernel.org
Closes: https://bugs.launchpad.net/neutron/+bug/2159935
Signed-off-by: Florian Westphal 
Signed-off-by: Greg Kroah-Hartman