* Re: [PATCH bpf-next v2] bpf, unix: Guard sk_msg-dependent code behind CONFIG_NET_SOCK_MSG
From: Jakub Sitnicki @ 2026-06-23 20:36 UTC (permalink / raw)
To: Amery Hung
Cc: Alexei Starovoitov, Kuniyuki Iwashima, bpf, Alexei Starovoitov,
Daniel Borkmann, Jakub Kicinski, Jiayuan Chen, John Fastabend,
Network Development, kernel-team
In-Reply-To: <CAMB2axMVhJJpP5HZtDFyQLLbKoRxhW08rj1zGRtWtgDkfYaVNA@mail.gmail.com>
On Tue, Jun 23, 2026 at 01:22 PM -07, Amery Hung wrote:
> On Tue, Jun 23, 2026 at 1:04 PM Jakub Sitnicki <jakub@cloudflare.com> wrote:
>>
>> On Tue, Jun 23, 2026 at 12:33 PM -07, Alexei Starovoitov wrote:
>> > On Tue, Jun 23, 2026 at 12:31 PM Kuniyuki Iwashima <kuniyu@google.com> wrote:
>> >>
>> >> On Tue, Jun 23, 2026 at 12:21 PM Jakub Sitnicki <jakub@cloudflare.com> wrote:
>> >> >
>> >> > On Tue, Jun 23, 2026 at 09:08 AM -07, Kuniyuki Iwashima wrote:
>> >> > > On Tue, Jun 23, 2026 at 4:20 AM Jakub Sitnicki <jakub@cloudflare.com> wrote:
>> >> > >>
>> >> > >> Prepare to decouple BPF_SYSCALL config option from NET_SOCK_MSG. When
>> >> > >> completed all code paths related to sockmap-based redirects should be
>> >> > >> guarded by BPF_SYSCALL && NET_SOCK_MSG to allow users to opt out by
>> >> > >> disabling NET_SOCK_MSG. The implementation of sockmap as a container for
>> >> > >> socket references would remain under BPF_SYSCALL.
>> >> > >>
>> >> > >> Signed-off-by: Jakub Sitnicki <jakub@cloudflare.com>
>> >> > >> ---
>> >> > >> Changes in v2:
>> >> > >> - Handle prot->recvmsg being NULL (Sashiko)
>> >> > >> - Elaborate on the end goal in description
>> >> > >> - Link to v1: https://patch.msgid.link/20260622-bpf-sk_msg-split-unix-v1-1-d7e0cb7bb03b@cloudflare.com
>> >> > >> ---
>> >> > >> net/unix/af_unix.c | 4 ++--
>> >> > >> net/unix/unix_bpf.c | 6 ++++++
>> >> > >> 2 files changed, 8 insertions(+), 2 deletions(-)
>> >> > >>
>> >> > >> diff --git a/net/unix/af_unix.c b/net/unix/af_unix.c
>> >> > >> index f7a9d55eee8a..84c11c60c75f 100644
>> >> > >> --- a/net/unix/af_unix.c
>> >> > >> +++ b/net/unix/af_unix.c
>> >> > >> @@ -2675,7 +2675,7 @@ static int unix_dgram_recvmsg(struct socket *sock, struct msghdr *msg, size_t si
>> >> > >> #ifdef CONFIG_BPF_SYSCALL
>> >> > >> const struct proto *prot = READ_ONCE(sk->sk_prot);
>> >> > >>
>> >> > >> - if (prot != &unix_dgram_proto)
>> >> > >> + if (prot->recvmsg)
>> >> > >
>> >> > > There is no reason to have this dead branch when
>> >> > > CONFIG_BPF_SYSCALL && !NET_SOCK_MSG.
>> >> > >
>> >> > > Let's compile out all sockmap code when both configs
>> >> > > are not enabled.
>> >> > >
>> >> > > Since AF_UNIX differs from TCP/UDP, it can take the
>> >> > > simpler approach.
>> >> >
>> >> > Okay, will put the whole file behind hidden config option like so:
>> >> >
>> >> > --- a/net/unix/Kconfig
>> >> > +++ b/net/unix/Kconfig
>> >> > @@ -30,3 +30,8 @@ config UNIX_DIAG
>> >> > help
>> >> > Support for UNIX socket monitoring interface used by the ss tool.
>> >> > If unsure, say Y.
>> >> > +
>> >> > +config UNIX_BPF
>> >>
>> >> Maybe UNIX_BPF_SOCKMAP or something.
>> >> bpf_iter is supported without this config.
>> >
>> > I don't like where it's going.
>> > I strongly dislike new config knobs.
>> > I'd rather remove existing knobs.
>> > What is the motivation?
>>
>> The goal is to compile out sockmap bits that use sk_msg.
>> NET_SOCK_MSG is natural, exisiting candidate.
>> New knob wasn't my idea.
>
> I'm also missing the big picture here.
>
> sockmap already holds socket references today. You can store and look
> up sockets without attaching any verdict/parser program, and no
> redirect happens. So if the goal is to use sockmap purely as a socket
> container without the sk_msg fast-path overhead, what does a
> compile-time NET_SOCK_MSG knob add over the runtime checks?
Sure, let me clarify. It's about the maintenance overhead.
sockmap-based redirects are a rather niche feature with few users, for
which we've been getting quite a few bug reports since AI came along.
We're not using it internally at Cloudflare, so I don't really have a
good reason to justify time spent on these bug reports.
Hence the move to put sockmap-based redirect behind a config option,
which you can enable at your own risk. Or which we can deprecate, but
that's not really my call.
> I am also not sure if NET_SOCK_MSG is right. It is broader than
> "sockmap redirect". It is selected by TLS and {INET,INET6}_ESPINTCP.
> Because those select it, it can't be toggled independently.
Once the sockmap redirect bits are behind _some_ config option, it will
be easy to replace it with a more granular one that depends on
NET_SOCK_MSG. But we're not there yet. One step at a time.
> Could you share the concrete use case you have in mind, and whether
> this came out of an earlier discussion or thread upstream?
This is a follow up from discussions at BPF summit with Alexei & John.
^ permalink raw reply
* Re: [PATCH net-next 0/3] selftests/xsk: stabilize timeout test behavior
From: Jakub Kicinski @ 2026-06-23 20:36 UTC (permalink / raw)
To: Maciej Fijalkowski
Cc: Jason Xing, Tushar Vyavahare, netdev, magnus.karlsson, stfomichev,
kernelxing, davem, pabeni, ast, daniel, tirthendu.sarkar, bpf
In-Reply-To: <ajqfDYznpCU18C2P@boxer>
On Tue, 23 Jun 2026 16:58:21 +0200 Maciej Fijalkowski wrote:
> On Tue, Jun 23, 2026 at 11:02:48AM +0200, Maciej Fijalkowski wrote:
> > last refactor from Tushar broke BIDIRECTIONAL test case when HW is test
> > target, but not on veth, so let me test these changes locally and then get
> > back to you.
> >
> > BPF CI runs xskxceiver on veth so this has not been caught. Seems my/our
> > focus should be to enable xskxceiver HW tests on any kind of
> > environment/infrastructure.
> >
> > Gonna get back to you by the EOD.
> > Maciej
>
> Ah I replied on other thread I guess, so let me repeat:
>
> Acked-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
> Tested-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
Great, thanks!
^ permalink raw reply
* Re: s2io: driver still in use - please reconsider removal
From: David Laight @ 2026-06-23 20:40 UTC (permalink / raw)
To: Michael Pratte
Cc: Jakub Kicinski, Paolo Abeni, Eric Dumazet, Ethan Nelson-Moore,
Andrew Lunn, Simon Horman, David S . Miller, netdev
In-Reply-To: <20260623112133.752195-1-slatoncomputers@gmail.com>
On Tue, 23 Jun 2026 06:21:33 -0500
Michael Pratte <slatoncomputers@gmail.com> wrote:
> Hi,
>
> Commit aba0138eb7d7 ("net: ethernet: neterion: s2io: remove unused
> driver") removed s2io in v7.0 as "highly unlikely to still be used."
> It is still in use here: an Exar Xframe-II (PCI 17d5:5832) in a
> Supermicro X5DA8.
Are you really using a dual socket netburst P4 system!
They weren't really any good when new :-)
David
^ permalink raw reply
* Re: [PATCH net] selftests: drv-net: so_txtime: relax variance bounds
From: patchwork-bot+netdevbpf @ 2026-06-23 20:40 UTC (permalink / raw)
To: Willem de Bruijn; +Cc: netdev, davem, kuba, edumazet, pabeni, horms, willemb
In-Reply-To: <20260621200137.1564776-1-willemdebruijn.kernel@gmail.com>
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Sun, 21 Jun 2026 16:01:18 -0400 you wrote:
> From: Willem de Bruijn <willemb@google.com>
>
> The net-next-hw spinners on netdev.bots.linux.dev observe failing
> so-txtime-py tests. A review of stdout shows most failures to be
> due to exceeding the 4ms grace period. All I saw were within 8ms.
> So increase to that.
>
> [...]
Here is the summary with links:
- [net] selftests: drv-net: so_txtime: relax variance bounds
https://git.kernel.org/netdev/net/c/e38fec239d92
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH v3 net] net: airoha: Fix TX scheduler queue mask loop upper bound
From: patchwork-bot+netdevbpf @ 2026-06-23 20:40 UTC (permalink / raw)
To: Wayen Yan
Cc: netdev, lorenzo, horms, pabeni, kuba, edumazet, andrew+netdev,
angelogioacchino.delregno, matthias.bgg, linux-arm-kernel,
linux-mediatek
In-Reply-To: <178187479434.2400840.1312143943526335838@gmail.com>
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Fri, 19 Jun 2026 21:12:06 +0800 you wrote:
> In airoha_qdma_set_chan_tx_sched(), the loop clearing queue mask was
> using AIROHA_NUM_TX_RING (32) instead of AIROHA_NUM_QOS_QUEUES (8).
>
> Each channel has 8 queues, and TXQ_DISABLE_CHAN_QUEUE_MASK(channel, i)
> computes BIT(i + (channel * 8)). With i ranging 0..31, this causes:
> - channel 0: clears bit 0..31 (all 4 channels) instead of 0..7
> - channel 1: clears bit 8..31 (channels 1-3) instead of 8..15
> - channel 2: clears bit 16..31 (channels 2-3) instead of 16..23
> - channel 3: clears bit 24..31 (channel 3 only) - correct by accident
>
> [...]
Here is the summary with links:
- [v3,net] net: airoha: Fix TX scheduler queue mask loop upper bound
https://git.kernel.org/netdev/net/c/245043dfc210
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH net] net, bpf: check master for NULL in xdp_master_redirect()
From: Jakub Kicinski @ 2026-06-23 20:43 UTC (permalink / raw)
To: Ido Schimmel
Cc: Xiang Mei, Jiayuan Chen, Daniel Borkmann, Martin KaFai Lau,
Jesper Dangaard Brouer, netdev, bpf, John Fastabend,
Stanislav Fomichev, Alexei Starovoitov, Jussi Maki, Paolo Abeni,
Weiming Shi, Ido Schimmel, David Ahern
In-Reply-To: <20260623065218.GA378121@shredder>
On Tue, 23 Jun 2026 09:52:18 +0300 Ido Schimmel wrote:
> On Mon, Jun 22, 2026 at 04:34:06PM -0700, Xiang Mei wrote:
> > On Mon, Jun 22, 2026 at 3:58 PM Jakub Kicinski <kuba@kernel.org> wrote:
> > > Can you double-confirm that this triggers on current HEAD
> > > of linux/master ? I thought commit 2674d603a9e6 ("vrf: Fix a potential
> > > NPD when removing a port from a VRF") was supposed to prevent all the
> > > torn master fetches. Adding VRF folks to CC.
> >
> > Yes.
> >
> > We have triggered the crash on 56abdaebbf0da304b860bed1f2b5a85f5a6a16a0,
> > which is the latest for net.git, and 2674d603a9e6 was applied. We can
> > still trigger the crash:
>
> 2674d603a9e6 was only for VRF ports, so it doesn't help with this case
> (bond port). Also, the problem that 2674d603a9e6 fixed is a bit
> different. We had a NULL check after netdev_master_upper_dev_get_rcu(),
> but the issue was that this master device was not necessarily a VRF
> master.
Ugh, sorry, my bad. Poor pattern matching of the bugs..
^ permalink raw reply
* Re: [PATCH bpf-next v2] bpf, unix: Guard sk_msg-dependent code behind CONFIG_NET_SOCK_MSG
From: Amery Hung @ 2026-06-23 20:44 UTC (permalink / raw)
To: Jakub Sitnicki
Cc: Alexei Starovoitov, Kuniyuki Iwashima, bpf, Alexei Starovoitov,
Daniel Borkmann, Jakub Kicinski, Jiayuan Chen, John Fastabend,
Network Development, kernel-team
In-Reply-To: <878q85yoy5.fsf@cloudflare.com>
On Tue, Jun 23, 2026 at 1:36 PM Jakub Sitnicki <jakub@cloudflare.com> wrote:
>
> On Tue, Jun 23, 2026 at 01:22 PM -07, Amery Hung wrote:
> > On Tue, Jun 23, 2026 at 1:04 PM Jakub Sitnicki <jakub@cloudflare.com> wrote:
> >>
> >> On Tue, Jun 23, 2026 at 12:33 PM -07, Alexei Starovoitov wrote:
> >> > On Tue, Jun 23, 2026 at 12:31 PM Kuniyuki Iwashima <kuniyu@google.com> wrote:
> >> >>
> >> >> On Tue, Jun 23, 2026 at 12:21 PM Jakub Sitnicki <jakub@cloudflare.com> wrote:
> >> >> >
> >> >> > On Tue, Jun 23, 2026 at 09:08 AM -07, Kuniyuki Iwashima wrote:
> >> >> > > On Tue, Jun 23, 2026 at 4:20 AM Jakub Sitnicki <jakub@cloudflare.com> wrote:
> >> >> > >>
> >> >> > >> Prepare to decouple BPF_SYSCALL config option from NET_SOCK_MSG. When
> >> >> > >> completed all code paths related to sockmap-based redirects should be
> >> >> > >> guarded by BPF_SYSCALL && NET_SOCK_MSG to allow users to opt out by
> >> >> > >> disabling NET_SOCK_MSG. The implementation of sockmap as a container for
> >> >> > >> socket references would remain under BPF_SYSCALL.
> >> >> > >>
> >> >> > >> Signed-off-by: Jakub Sitnicki <jakub@cloudflare.com>
> >> >> > >> ---
> >> >> > >> Changes in v2:
> >> >> > >> - Handle prot->recvmsg being NULL (Sashiko)
> >> >> > >> - Elaborate on the end goal in description
> >> >> > >> - Link to v1: https://patch.msgid.link/20260622-bpf-sk_msg-split-unix-v1-1-d7e0cb7bb03b@cloudflare.com
> >> >> > >> ---
> >> >> > >> net/unix/af_unix.c | 4 ++--
> >> >> > >> net/unix/unix_bpf.c | 6 ++++++
> >> >> > >> 2 files changed, 8 insertions(+), 2 deletions(-)
> >> >> > >>
> >> >> > >> diff --git a/net/unix/af_unix.c b/net/unix/af_unix.c
> >> >> > >> index f7a9d55eee8a..84c11c60c75f 100644
> >> >> > >> --- a/net/unix/af_unix.c
> >> >> > >> +++ b/net/unix/af_unix.c
> >> >> > >> @@ -2675,7 +2675,7 @@ static int unix_dgram_recvmsg(struct socket *sock, struct msghdr *msg, size_t si
> >> >> > >> #ifdef CONFIG_BPF_SYSCALL
> >> >> > >> const struct proto *prot = READ_ONCE(sk->sk_prot);
> >> >> > >>
> >> >> > >> - if (prot != &unix_dgram_proto)
> >> >> > >> + if (prot->recvmsg)
> >> >> > >
> >> >> > > There is no reason to have this dead branch when
> >> >> > > CONFIG_BPF_SYSCALL && !NET_SOCK_MSG.
> >> >> > >
> >> >> > > Let's compile out all sockmap code when both configs
> >> >> > > are not enabled.
> >> >> > >
> >> >> > > Since AF_UNIX differs from TCP/UDP, it can take the
> >> >> > > simpler approach.
> >> >> >
> >> >> > Okay, will put the whole file behind hidden config option like so:
> >> >> >
> >> >> > --- a/net/unix/Kconfig
> >> >> > +++ b/net/unix/Kconfig
> >> >> > @@ -30,3 +30,8 @@ config UNIX_DIAG
> >> >> > help
> >> >> > Support for UNIX socket monitoring interface used by the ss tool.
> >> >> > If unsure, say Y.
> >> >> > +
> >> >> > +config UNIX_BPF
> >> >>
> >> >> Maybe UNIX_BPF_SOCKMAP or something.
> >> >> bpf_iter is supported without this config.
> >> >
> >> > I don't like where it's going.
> >> > I strongly dislike new config knobs.
> >> > I'd rather remove existing knobs.
> >> > What is the motivation?
> >>
> >> The goal is to compile out sockmap bits that use sk_msg.
> >> NET_SOCK_MSG is natural, exisiting candidate.
> >> New knob wasn't my idea.
> >
> > I'm also missing the big picture here.
> >
> > sockmap already holds socket references today. You can store and look
> > up sockets without attaching any verdict/parser program, and no
> > redirect happens. So if the goal is to use sockmap purely as a socket
> > container without the sk_msg fast-path overhead, what does a
> > compile-time NET_SOCK_MSG knob add over the runtime checks?
>
> Sure, let me clarify. It's about the maintenance overhead.
>
> sockmap-based redirects are a rather niche feature with few users, for
> which we've been getting quite a few bug reports since AI came along.
>
> We're not using it internally at Cloudflare, so I don't really have a
> good reason to justify time spent on these bug reports.
>
> Hence the move to put sockmap-based redirect behind a config option,
> which you can enable at your own risk. Or which we can deprecate, but
> that's not really my call.
>
> > I am also not sure if NET_SOCK_MSG is right. It is broader than
> > "sockmap redirect". It is selected by TLS and {INET,INET6}_ESPINTCP.
> > Because those select it, it can't be toggled independently.
>
> Once the sockmap redirect bits are behind _some_ config option, it will
> be easy to replace it with a more granular one that depends on
> NET_SOCK_MSG. But we're not there yet. One step at a time.
>
> > Could you share the concrete use case you have in mind, and whether
> > this came out of an earlier discussion or thread upstream?
>
> This is a follow up from discussions at BPF summit with Alexei & John.
I see. Thanks for explaining the motivation.
^ permalink raw reply
* Re: [PATCH net-next 0/3] selftests/xsk: stabilize timeout test behavior
From: patchwork-bot+netdevbpf @ 2026-06-23 20:50 UTC (permalink / raw)
To: Tushar Vyavahare
Cc: netdev, magnus.karlsson, maciej.fijalkowski, stfomichev,
kernelxing, davem, kuba, pabeni, ast, daniel, tirthendu.sarkar,
bpf
In-Reply-To: <20260616154955.1492560-1-tushar.vyavahare@intel.com>
Hello:
This series was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Tue, 16 Jun 2026 21:19:51 +0530 you wrote:
> This series improves AF_XDP selftests by making timeout handling
> explicit and fixing sources of non-determinism in xsk timeout tests.
>
> Patch 1 introduces test_spec::poll_tmout and removes implicit
> dependence on RX UMEM setup state for timeout behavior.
>
> Patch 2 fixes thread harness sequencing by attaching XDP programs
> before worker startup, removing signal-based termination, and using
> barrier synchronization only for dual-thread runs.
>
> [...]
Here is the summary with links:
- [net-next,1/3] selftests/xsk: make poll timeout mode explicit
https://git.kernel.org/netdev/net/c/b56cded13137
- [net-next,2/3] selftests/xsk: fix timeout thread harness sequencing
https://git.kernel.org/netdev/net/c/483c1405f817
- [net-next,3/3] selftests/xsk: restore shared_umem after POLL_TXQ_FULL
https://git.kernel.org/netdev/net/c/ea4e9c9d8b2b
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH] net: ipa: fix SMEM state handle leaks in SMP2P init
From: Jakub Kicinski @ 2026-06-23 21:06 UTC (permalink / raw)
To: Haoxiang Li
Cc: Alex Elder, elder, andrew+netdev, davem, edumazet, pabeni, netdev,
linux-kernel, stable
In-Reply-To: <526c68fd-684d-4593-8c6a-e08aafdada5d@ieee.org>
On Tue, 23 Jun 2026 10:53:49 -0500 Alex Elder wrote:
> So I guess they were never "put" before?
>
> This looks OK, but I'll just mention that the IPA code
> doesn't use devm_*() (managed) interfaces. So it would
> be more consistent to just call qcom_smem_state_put()
> at the end of ipa_smp2p_exit() for both ipa->enabled_state
> and ipa->valid_state.
Let's do that instead. The devm_ APIs prevent about as many bugs
as they cause.
^ permalink raw reply
* Re: [PATCH net] net, bpf: check master for NULL in xdp_master_redirect()
From: patchwork-bot+netdevbpf @ 2026-06-23 21:10 UTC (permalink / raw)
To: Xiang Mei
Cc: daniel, martin.lau, hawk, jiayuan.chen, netdev, bpf,
john.fastabend, sdf, ast, joamaki, pabeni, bestswngs
In-Reply-To: <20260620201531.180123-1-xmei5@asu.edu>
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Sat, 20 Jun 2026 13:15:31 -0700 you wrote:
> xdp_master_redirect() dereferences the result of
> netdev_master_upper_dev_get_rcu() without a NULL check, but that helper
> returns NULL when the receiving device has no upper-master adjacency.
>
> The reach guard only checks netif_is_bond_slave(). On bond slave release
> bond_upper_dev_unlink() drops the upper-master adjacency before clearing
> IFF_SLAVE, so an XDP_TX reaching xdp_master_redirect() in that window
> still passes netif_is_bond_slave() while master is already NULL, and
> faults on master->flags at offset 0xb0:
>
> [...]
Here is the summary with links:
- [net] net, bpf: check master for NULL in xdp_master_redirect()
https://git.kernel.org/netdev/net/c/e82d8cc4321c
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH bpf 1/2] bpf, sockmap: Don't leak UDP socks on lookup-bind-release
From: Emil Tsalapatis @ 2026-06-23 21:19 UTC (permalink / raw)
To: Michal Luczaj, John Fastabend, Jakub Sitnicki, Jiayuan Chen,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, Alexei Starovoitov, Cong Wang, Daniel Borkmann,
Andrii Nakryiko, Eduard Zingerman, Kumar Kartikeya Dwivedi,
Martin KaFai Lau, Song Liu, Yonghong Song, Jiri Olsa,
Emil Tsalapatis, Shuah Khan
Cc: netdev, bpf, linux-kernel, linux-kselftest
In-Reply-To: <20260623-sockmap-lookup-udp-leak-v1-1-05804f9308e4@rbox.co>
On Tue Jun 23, 2026 at 2:03 PM EDT, Michal Luczaj wrote:
> UDP sockets get SOCK_RCU_FREE set when (auto-)bound. This means
> sk_is_refcounted(unbound) = true, while sk_is_refcounted(bound) = false.
>
> Because sockmap accepts unbound UDP sockets, a BPF program can increment a
> socket's refcount via lookup. If the socket is subsequently bound, the
> transition from unbound to bound causes bpf_sk_release() to skip the
> decrement of the refcount, causing a memory leak.
>
> unreferenced object 0xffff88810bc2eb40 (size 1984):
> comm "test_progs", pid 2451, jiffies 4295320596
> hex dump (first 32 bytes):
> 7f 00 00 01 7f 00 00 01 d2 04 1b b7 04 d2 00 00 ................
> 02 00 01 40 00 00 00 00 00 00 00 00 00 00 00 00 ...@............
> backtrace (crc bdee079d):
> kmem_cache_alloc_noprof+0x557/0x660
> sk_prot_alloc+0x69/0x240
> sk_alloc+0x30/0x460
> inet_create+0x2ce/0xf80
> __sock_create+0x25b/0x5c0
> __sys_socket+0x119/0x1d0
> __x64_sys_socket+0x72/0xd0
> do_syscall_64+0xa1/0x5f0
> entry_SYSCALL_64_after_hwframe+0x76/0x7e
>
> Maintain balanced refcounts across sk lookup/release: (re-)set
> SOCK_RCU_FREE on proto update to treat the socket (whether bound or
> unbound) as not requiring a refcount increment on (a RCU protected) lookup.
>
> Fixes: 0c48eefae712 ("sock_map: Lift socket state restriction for datagram sockets")
> Signed-off-by: Michal Luczaj <mhal@rbox.co>
Reviewed-by: Emil Tsalapatis <emil@etsalapatis.com>
> ---
> Note: this issue is related to commit 67312adc96b5 ("bpf: reject unhashed
> sockets in bpf_sk_assign").
> ---
> net/ipv4/udp_bpf.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/net/ipv4/udp_bpf.c b/net/ipv4/udp_bpf.c
> index ad57c4c9eaab..970327b59582 100644
> --- a/net/ipv4/udp_bpf.c
> +++ b/net/ipv4/udp_bpf.c
> @@ -173,6 +173,9 @@ int udp_bpf_update_proto(struct sock *sk, struct sk_psock *psock, bool restore)
> if (sk->sk_family == AF_INET6)
> udp_bpf_check_v6_needs_rebuild(psock->sk_proto);
>
> + /* Treat all sockets as non-refcounted, regardless of binding state. */
> + sock_set_flag(sk, SOCK_RCU_FREE);
> +
> sock_replace_proto(sk, &udp_bpf_prots[family]);
> return 0;
> }
^ permalink raw reply
* Re: [PATCH bpf-next v2] bpf, unix: Guard sk_msg-dependent code behind CONFIG_NET_SOCK_MSG
From: Alexei Starovoitov @ 2026-06-23 21:26 UTC (permalink / raw)
To: Jakub Sitnicki
Cc: Amery Hung, Kuniyuki Iwashima, bpf, Alexei Starovoitov,
Daniel Borkmann, Jakub Kicinski, Jiayuan Chen, John Fastabend,
Network Development, kernel-team
In-Reply-To: <878q85yoy5.fsf@cloudflare.com>
On Tue, Jun 23, 2026 at 1:36 PM Jakub Sitnicki <jakub@cloudflare.com> wrote:
>
> On Tue, Jun 23, 2026 at 01:22 PM -07, Amery Hung wrote:
> > On Tue, Jun 23, 2026 at 1:04 PM Jakub Sitnicki <jakub@cloudflare.com> wrote:
> >>
> >> On Tue, Jun 23, 2026 at 12:33 PM -07, Alexei Starovoitov wrote:
> >> > On Tue, Jun 23, 2026 at 12:31 PM Kuniyuki Iwashima <kuniyu@google.com> wrote:
> >> >>
> >> >> On Tue, Jun 23, 2026 at 12:21 PM Jakub Sitnicki <jakub@cloudflare.com> wrote:
> >> >> >
> >> >> > On Tue, Jun 23, 2026 at 09:08 AM -07, Kuniyuki Iwashima wrote:
> >> >> > > On Tue, Jun 23, 2026 at 4:20 AM Jakub Sitnicki <jakub@cloudflare.com> wrote:
> >> >> > >>
> >> >> > >> Prepare to decouple BPF_SYSCALL config option from NET_SOCK_MSG. When
> >> >> > >> completed all code paths related to sockmap-based redirects should be
> >> >> > >> guarded by BPF_SYSCALL && NET_SOCK_MSG to allow users to opt out by
> >> >> > >> disabling NET_SOCK_MSG. The implementation of sockmap as a container for
> >> >> > >> socket references would remain under BPF_SYSCALL.
> >> >> > >>
> >> >> > >> Signed-off-by: Jakub Sitnicki <jakub@cloudflare.com>
> >> >> > >> ---
> >> >> > >> Changes in v2:
> >> >> > >> - Handle prot->recvmsg being NULL (Sashiko)
> >> >> > >> - Elaborate on the end goal in description
> >> >> > >> - Link to v1: https://patch.msgid.link/20260622-bpf-sk_msg-split-unix-v1-1-d7e0cb7bb03b@cloudflare.com
> >> >> > >> ---
> >> >> > >> net/unix/af_unix.c | 4 ++--
> >> >> > >> net/unix/unix_bpf.c | 6 ++++++
> >> >> > >> 2 files changed, 8 insertions(+), 2 deletions(-)
> >> >> > >>
> >> >> > >> diff --git a/net/unix/af_unix.c b/net/unix/af_unix.c
> >> >> > >> index f7a9d55eee8a..84c11c60c75f 100644
> >> >> > >> --- a/net/unix/af_unix.c
> >> >> > >> +++ b/net/unix/af_unix.c
> >> >> > >> @@ -2675,7 +2675,7 @@ static int unix_dgram_recvmsg(struct socket *sock, struct msghdr *msg, size_t si
> >> >> > >> #ifdef CONFIG_BPF_SYSCALL
> >> >> > >> const struct proto *prot = READ_ONCE(sk->sk_prot);
> >> >> > >>
> >> >> > >> - if (prot != &unix_dgram_proto)
> >> >> > >> + if (prot->recvmsg)
> >> >> > >
> >> >> > > There is no reason to have this dead branch when
> >> >> > > CONFIG_BPF_SYSCALL && !NET_SOCK_MSG.
> >> >> > >
> >> >> > > Let's compile out all sockmap code when both configs
> >> >> > > are not enabled.
> >> >> > >
> >> >> > > Since AF_UNIX differs from TCP/UDP, it can take the
> >> >> > > simpler approach.
> >> >> >
> >> >> > Okay, will put the whole file behind hidden config option like so:
> >> >> >
> >> >> > --- a/net/unix/Kconfig
> >> >> > +++ b/net/unix/Kconfig
> >> >> > @@ -30,3 +30,8 @@ config UNIX_DIAG
> >> >> > help
> >> >> > Support for UNIX socket monitoring interface used by the ss tool.
> >> >> > If unsure, say Y.
> >> >> > +
> >> >> > +config UNIX_BPF
> >> >>
> >> >> Maybe UNIX_BPF_SOCKMAP or something.
> >> >> bpf_iter is supported without this config.
> >> >
> >> > I don't like where it's going.
> >> > I strongly dislike new config knobs.
> >> > I'd rather remove existing knobs.
> >> > What is the motivation?
> >>
> >> The goal is to compile out sockmap bits that use sk_msg.
> >> NET_SOCK_MSG is natural, exisiting candidate.
> >> New knob wasn't my idea.
> >
> > I'm also missing the big picture here.
> >
> > sockmap already holds socket references today. You can store and look
> > up sockets without attaching any verdict/parser program, and no
> > redirect happens. So if the goal is to use sockmap purely as a socket
> > container without the sk_msg fast-path overhead, what does a
> > compile-time NET_SOCK_MSG knob add over the runtime checks?
>
> Sure, let me clarify. It's about the maintenance overhead.
>
> sockmap-based redirects are a rather niche feature with few users, for
> which we've been getting quite a few bug reports since AI came along.
>
> We're not using it internally at Cloudflare, so I don't really have a
> good reason to justify time spent on these bug reports.
>
> Hence the move to put sockmap-based redirect behind a config option,
> which you can enable at your own risk. Or which we can deprecate, but
> that's not really my call.
This is wishful thinking that a config knob will stop
the bug reports.
Just disable it for real instead.
> > I am also not sure if NET_SOCK_MSG is right. It is broader than
> > "sockmap redirect". It is selected by TLS and {INET,INET6}_ESPINTCP.
> > Because those select it, it can't be toggled independently.
>
> Once the sockmap redirect bits are behind _some_ config option, it will
> be easy to replace it with a more granular one that depends on
> NET_SOCK_MSG. But we're not there yet. One step at a time.
No. That's not workable.
> > Could you share the concrete use case you have in mind, and whether
> > this came out of an earlier discussion or thread upstream?
>
> This is a follow up from discussions at BPF summit with Alexei & John.
Not quite. The discussion was to disable pieces of sockmap
that are causing trouble.
Not to move them under config knobs, but disable them.
^ permalink raw reply
* Re: [PATCH net v2] net: dsa: sja1105: round up PTP perout pin duration
From: patchwork-bot+netdevbpf @ 2026-06-23 21:50 UTC (permalink / raw)
To: Aleksandrova Alyona
Cc: olteanv, andrew, f.fainelli, davem, edumazet, kuba, pabeni,
richardcochran, linux-kernel, netdev, lvc-project
In-Reply-To: <20260618110508.53094-1-aga@itb.spb.ru>
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Thu, 18 Jun 2026 14:05:08 +0300 you wrote:
> pin_duration is converted from the user-provided period to SJA1105
> clock ticks and is later passed as the cycle_time argument to
> future_base_time().
>
> Very small period values may become zero after the conversion,
> which can lead to a division by zero in future_base_time().
>
> [...]
Here is the summary with links:
- [net,v2] net: dsa: sja1105: round up PTP perout pin duration
https://git.kernel.org/netdev/net/c/aee5836273b0
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH net] net: do not acquire dev->tx_global_lock in netdev_watchdog_up()
From: patchwork-bot+netdevbpf @ 2026-06-23 21:50 UTC (permalink / raw)
To: Eric Dumazet
Cc: davem, kuba, pabeni, horms, netdev, eric.dumazet, m.szyprowski
In-Reply-To: <20260622110108.69541-1-edumazet@google.com>
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Mon, 22 Jun 2026 11:01:08 +0000 you wrote:
> Marek Szyprowski reported a deadlock during system resume when virtio_net
> driver is used.
>
> The deadlock occurs because netif_device_attach() is called while holding
> dev->tx_global_lock (via netif_tx_lock_bh() in virtnet_restore_up()).
> netif_device_attach() calls __netdev_watchdog_up(), which now also tries
> to acquire dev->tx_global_lock to synchronize with dev_watchdog().
>
> [...]
Here is the summary with links:
- [net] net: do not acquire dev->tx_global_lock in netdev_watchdog_up()
https://git.kernel.org/netdev/net/c/d09a78a2a469
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH net] veth: fix NAPI leak in XDP enable error path
From: patchwork-bot+netdevbpf @ 2026-06-23 21:50 UTC (permalink / raw)
To: Eric Dumazet
Cc: davem, kuba, pabeni, horms, netdev, eric.dumazet, groeck,
bjorn.topel, daniel, ilias.apalodimas, mst, tariqt
In-Reply-To: <20260622111825.88337-1-edumazet@google.com>
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Mon, 22 Jun 2026 11:18:25 +0000 you wrote:
> During XDP enablement in veth, if xdp_rxq_info_reg() or
> xdp_rxq_info_reg_mem_model() fails, the driver rolls back the changes.
>
> However, the rollback loop:
> for (i--; i >= start; i--) {
>
> decrements the loop index 'i' before the first iteration. This
> correctly skips unregistering the rxq for the failed index 'i' (as
> registration failed or was already cleaned up), but it also
> erroneously skips calling netif_napi_deli() for rq[i].xdp_napi.
>
> [...]
Here is the summary with links:
- [net] veth: fix NAPI leak in XDP enable error path
https://git.kernel.org/netdev/net/c/6739027cb72d
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH net v2] net: ti: icssg: Fix XSK zero copy TX during application wakeup
From: patchwork-bot+netdevbpf @ 2026-06-23 21:50 UTC (permalink / raw)
To: Meghana Malladi
Cc: diogo.ivo, vadim.fedorenko, haokexin, devnexen, horms,
jacob.e.keller, pabeni, kuba, edumazet, davem, andrew+netdev,
linux-kernel, netdev, linux-arm-kernel, srk, vigneshr, rogerq,
danishanwar
In-Reply-To: <20260618100348.2209907-1-m-malladi@ti.com>
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Thu, 18 Jun 2026 15:33:48 +0530 you wrote:
> emac_xsk_xmit_zc() handles tx xmit for zero copy and gets called
> inside napi context. User application wakes up the kernel while
> initiating the transmit which triggers napi to start processing
> the tx packets. The num_tx check inside emac_tx_complete_packets()
> returns early if no packet transfer happen hindering the call
> to emac_xsk_xmit_zc(). Remove this check to let application
> wakeup initiate zero copy xmit traffic.
>
> [...]
Here is the summary with links:
- [net,v2] net: ti: icssg: Fix XSK zero copy TX during application wakeup
https://git.kernel.org/netdev/net/c/d95ea4bc09e8
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: s2io: driver still in use - please reconsider removal
From: Michael Pratte @ 2026-06-23 22:11 UTC (permalink / raw)
To: Ethan Nelson-Moore
Cc: Jakub Kicinski, Paolo Abeni, Eric Dumazet, Andrew Lunn,
Simon Horman, David S . Miller, netdev
In-Reply-To: <CADkSEUhkWRzW+-39JmkDSjUi8Qfwrr0qsVJFDxZhpNCBSenMyw@mail.gmail.com>
On Tue, Jun 23, 2026, Ethan Nelson-Moore wrote:
> Are you using the card for actual work, or are you just testing it out
> of curiosity? What kernel version were you running before you upgraded
> to a current kernel?
A mix of both. I run and maintain a lot of older hardware, some for
work and some for fun, and a 10G card that works in PCI-X has been
hard to find. I brought this one up directly on 6.6, so I hadn't run
it on an older kernel; I bisected afterward and found it last worked
in 4.1.
> Given that the driver has not been working for almost 11 years and you
> are seemingly the first person to notice, I would like to respectfully
> disagree with this assertion.
I might well be the only one still using it. But it's a one-line fix,
and I'm willing to maintain it going forward if that helps keep it in
tree.
Thanks,
Michael
^ permalink raw reply
* [PATCH net 00/14] Netfilter fixes for net
From: Pablo Neira Ayuso @ 2026-06-23 22:15 UTC (permalink / raw)
To: netfilter-devel; +Cc: davem, netdev, kuba, pabeni, edumazet, fw, horms
Hi,
The following patchset contains Netfilter fixes for net:
1) Add a workaround to avoid a possible crash if nf_nat and nft_chain_nat are
compiled built-in and nf_nat fails to register, allowing nft_chain_nat to
access the incorrect pernetns area. This is crash specific of all built-in
compilation. From Matias Krause.
2) Revisit conncount GC optimization for confirmed conntracks, skip GC round
if IPS_ASSURED is set on. This is addressing an issue for corner case
use case scenario involving locally generated traffic. No crash, just a
functionality fix. From Fernando F. Mancera.
3) Validate iph->ihl in flowtable IPIP tunnel support, from Lorenzo Bianconi.
This a sanity check to bounces back malformed IPIP packets to classic
forwarding path.
4) Kdoc fixes for x_tables.h, from Randy Dunlap.
5) Use info->options so nft_synproxy_tcp_options() stays on the same local
snapshot, otherwise eval path can observe inconsistent mix of mss and
timestamps. From Runyu Xiao.
6) Add conntrack_sctp_collision.sh to cover for SCTP INIT collisions.
From Yi Chen.
7) Do not allow NFPROTO_UNSPEC targets if family is NFPROTO_BRIDGE in
nft_compat. This allows to use non-sense targets such as xt_nat leading
to crash. From Florian Westphal.
8) Add a selftest queueing from bridge family. From Florian Westphal.
9) Do not allow to reset a conntrack helper via ctnetlink. This feature
antedates the creation of the conntrack-tools, and it is not used
I don't have a usecase for it, I prefer to remove than fixing it.
10) Add deprecation warning for IPv4 only conntrack helpers for PPTP
and IRC. From Florian Westphal.
11) Store the master tuple in the expectation object and use it,
otherwise SLAB_TYPESAFE_RCU rules allow to display incorrect
master tuple information through ctnetlink.
12) Run expectation eviction when inserting an expectation with no
helper, this is a fix for the nft_ct custom expectation support.
13) Fix nft_ct custom expectation timeouts, userspace provides a
timeout in milliseconds but kernel assumes this comes in seconds.
From Florian Westphal.
14) Cap maximum number of expectations per class to 255 expectations
per master conntrack at helper registration. This is a fix to
restrict the maximum number of expectations per master conntrack
which can be a issue for the new lazy GC expectation approach.
Please, pull these changes from:
git://git.kernel.org/pub/scm/linux/kernel/git/netfilter/nf.git nf-26-06-23
Thanks.
P.S: Sashiko has been reporting "Failed to apply" with recent patches,
I suspect it relies on the Linus' tree which does not contain
yet the patches that were recently included in the last PR.
If it fails to deliver a report, I can provide a list of list
to the reviews that sashiko provided when patches were posted to
the netfilter-devel mailing list.
----------------------------------------------------------------
The following changes since commit a986fde914d88af47eb78fd29c5d1af7952c3500:
bnx2x: fix potential memory leak in bnx2x_alloc_mem_bp() (2026-06-22 18:39:12 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/netfilter/nf.git tags/nf-26-06-23
for you to fetch changes up to 397c8300972f6e1486fd1afd99a044648a401cd5:
netfilter: nf_conntrack_helper: cap maximum number of expectation at helper registration (2026-06-23 13:10:48 +0200)
----------------------------------------------------------------
netfilter pull request 26-06-23
----------------------------------------------------------------
Fernando Fernandez Mancera (1):
netfilter: nf_conncount: prevent connlimit drops for early confirmed ct
Florian Westphal (4):
netfilter: nft_compat: ebtables emulation must reject non-bridge targets
selftests: nft_queue.sh: add a bridge queue test
netfilter: conntrack: add deprecation warnings for irc and pptp trackers
netfilter: nft_ct: expectation timeouts are passed in milliseconds
Lorenzo Bianconi (1):
netfilter: flowtable: Validate iph->ihl in nf_flow_ip4_tunnel_proto()
Mathias Krause (1):
netfilter: nf_nat: avoid invalid nat_net pointer use on failed nf_nat_init()
Pablo Neira Ayuso (4):
netfilter: ctnetlink: do not allow to reset helper on existing conntrack
netfilter: nf_conntrack_expect: store master_tuple in expectation
netfilter: nf_conntrack_expect: run expectation eviction with no helper
netfilter: nf_conntrack_helper: cap maximum number of expectation at helper registration
Randy Dunlap (1):
netfilter: x_tables.h: fix all kernel-doc warnings
Runyu Xiao (1):
netfilter: nft_synproxy: stop bypassing the priv->info snapshot
Yi Chen (1):
selftests: netfilter: conntrack_sctp_collision.sh: Introduce SCTP INIT collision test
include/linux/netfilter/x_tables.h | 29 +++++--
include/net/netfilter/nf_conntrack_expect.h | 1 +
include/net/netfilter/nf_conntrack_helper.h | 4 +
net/netfilter/Kconfig | 11 +--
net/netfilter/nf_conncount.c | 11 ++-
net/netfilter/nf_conntrack_broadcast.c | 1 +
net/netfilter/nf_conntrack_expect.c | 12 ++-
net/netfilter/nf_conntrack_helper.c | 9 ++-
net/netfilter/nf_conntrack_irc.c | 2 +
net/netfilter/nf_conntrack_netlink.c | 23 +-----
net/netfilter/nf_conntrack_pptp.c | 2 +
net/netfilter/nf_flow_table_ip.c | 8 +-
net/netfilter/nf_nat_core.c | 10 +++
net/netfilter/nft_compat.c | 24 +++++-
net/netfilter/nft_ct.c | 21 ++++-
net/netfilter/nft_synproxy.c | 9 +--
.../net/netfilter/conntrack_sctp_collision.sh | 89 ++++++++++++++++------
tools/testing/selftests/net/netfilter/nft_queue.sh | 66 ++++++++++++++--
18 files changed, 246 insertions(+), 86 deletions(-)
^ permalink raw reply
* [PATCH net 01/14] netfilter: nf_nat: avoid invalid nat_net pointer use on failed nf_nat_init()
From: Pablo Neira Ayuso @ 2026-06-23 22:15 UTC (permalink / raw)
To: netfilter-devel; +Cc: davem, netdev, kuba, pabeni, edumazet, fw, horms
In-Reply-To: <20260623221548.701545-1-pablo@netfilter.org>
From: Mathias Krause <minipli@grsecurity.net>
We ran into below KASAN splat, which is mostly uninteresting, beside
for having nf_nat_register_fn() in the call chain as a cause for the
offending access:
==================================================================
BUG: KASAN: slab-out-of-bounds in nf_nat_register_fn+0x5f9/0x640
Read of size 8 at addr ffff890031e54c20 by task iptables/9510
CPU: 0 UID: 0 PID: 9510 Comm: iptables Not tainted 6.18.18-grsec-full-20260320181326 #1 PREEMPT(voluntary)
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
Call Trace:
<TASK>
[…] dump_stack_lvl+0xee/0x160 ffff88004117eeb8
[…] print_report+0x6e/0x640 ffff88004117eee0
[…] ? __phys_addr+0x8e/0x140 ffff88004117eef0
[…] ? kasan_addr_to_slab+0x51/0xe0 ffff88004117ef08
[…] ? complete_report_info+0xec/0x1c0 ffff88004117ef20
[…] ? nf_nat_register_fn+0x5f9/0x640 ffff88004117ef48
[…] kasan_report+0xbc/0x140 ffff88004117ef50
[…] ? nf_nat_register_fn+0x5f9/0x640 ffff88004117ef90
[…] nf_nat_register_fn+0x5f9/0x640 ffff88004117eff8
[…] ? nf_nat_icmp_reply_translation+0x6e0/0x6e0 ffff88004117f070
[…] nf_tables_register_hook.part.0+0xa0/0x220 ffff88004117f080
[…] nf_tables_addchain.constprop.0+0x1054/0x1fc0 ffff88004117f0b8
[…] ? nft_chain_lookup.part.0+0x4ce/0xac0 ffff88004117f130
[…] ? nf_tables_abort+0x3d80/0x3d80 ffff88004117f190
[…] ? nf_tables_dumpreset_obj+0x100/0x100 ffff88004117f1c8
[…] ? nft_table_lookup.part.0+0x255/0x300 ffff88004117f310
[…] ? nf_tables_newchain+0x21a4/0x2fa0 ffff88004117f358
[…] nf_tables_newchain+0x21a4/0x2fa0 ffff88004117f360
[…] ? nf_tables_addchain.constprop.0+0x1fc0/0x1fc0 ffff88004117f458
[…] ? nla_get_range_signed+0x4a0/0x4a0 ffff88004117f488
[…] ? lock_acquire+0x16f/0x320 ffff88004117f490
[…] ? find_held_lock+0x3b/0xe0 ffff88004117f4b0
[…] ? __nla_parse+0x45/0x80 ffff88004117f500
[…] nfnetlink_rcv_batch+0xbca/0x19a0 ffff88004117f550
[…] ? nfnetlink_net_exit_batch+0x120/0x120 ffff88004117f618
[…] ? __sanitizer_cov_trace_switch+0x63/0xe0 ffff88004117f720
[…] ? gr_acl_handle_mmap+0x1c4/0x320 ffff88004117f7c0
[…] ? nla_get_range_signed+0x4a0/0x4a0 ffff88004117f7e8
[…] ? gr_is_capable+0x6f/0xe0 ffff88004117f830
[…] ? __nla_parse+0x45/0x80 ffff88004117f860
[…] ? skb_pull+0x103/0x1a0 ffff88004117f880
[…] nfnetlink_rcv+0x3db/0x4a0 ffff88004117f8b0
[…] ? nfnetlink_rcv_batch+0x19a0/0x19a0 ffff88004117f8d8
[…] ? netlink_lookup+0xe2/0x240 ffff88004117f900
[…] netlink_unicast+0x74b/0xb00 ffff88004117f930
[…] ? netlink_attachskb+0xb20/0xb20 ffff88004117f980
[…] ? __check_object_size+0x3e/0xaa0 ffff88004117f998
[…] ? security_netlink_send+0x51/0x160 ffff88004117f9c8
[…] netlink_sendmsg+0xa03/0x1200 ffff88004117f9f8
[…] ? netlink_unicast+0xb00/0xb00 ffff88004117fa70
[…] ? netlink_unicast+0xb00/0xb00 ffff88004117fac8
[…] ? ____sys_sendmsg+0xe2a/0x1040 ffff88004117faf8
[…] ____sys_sendmsg+0xe2a/0x1040 ffff88004117fb00
[…] ? kernel_recvmsg+0x300/0x300 ffff88004117fb60
[…] ? reacquire_held_locks+0xe9/0x260 ffff88004117fbc8
[…] ___sys_sendmsg+0x138/0x200 ffff88004117fbf8
[…] ? do_recvmmsg+0x7e0/0x7e0 ffff88004117fc30
[…] ? lockdep_hardirqs_on_prepare+0x101/0x1e0 ffff88004117fc50
[…] ? lock_acquire+0x16f/0x320 ffff88004117fd20
[…] ? lock_acquire+0x16f/0x320 ffff88004117fd58
[…] ? find_held_lock+0x3b/0xe0 ffff88004117fd70
[…] __sys_sendmsg+0x17a/0x260 ffff88004117fdc8
[…] ? __sys_sendmsg_sock+0x80/0x80 ffff88004117fdf0
[…] ? syscall_trace_enter+0x15e/0x2c0 ffff88004117fe98
[…] do_syscall_64+0x7d/0x400 ffff88004117fec8
[…] entry_SYSCALL_64_safe_stack+0x4a/0x60 ffff88004117fef8
</TASK>
==================================================================
The out-of-bounds report, though, is a red herring as it is for an
access that shouldn't have happened in the first place.
When nf_nat_init() fails to register its BPF kfuncs, it'll unwind and,
among others, call unregister_pernet_subsys() to deregister its per-net
ops. This makes the previously allocated net id available for reuse by
the next caller of register_pernet_subsys(), in our case, synproxy.
However, 'nat_net_id' will still hold the previously allocated value.
If nf_nat.o gets build as a module, all this doesn't matter. A failed
initialization routine makes the module fail to load and any dependent
module won't be able to load either. However, if nf_nat.o is built-in,
a failing init won't /completely/ make its functionality unavailable to
dependent modules, namely the code and static data is still there, free
to be called by modules like nft_chain_nat.ko.
Case in point, nft_chain_nat registers hooks that'll call into nf_nat
which, in our case, failed to initialize and therefore won't have a
valid net id nor related net_nat object any more.
Code in nf_nat, namely nf_nat_register_fn() and nf_nat_unregister_fn(),
still making use of the reallocated net id, lead to a type confusion as
the call to net_generic() will no longer return memory belonging to an
object suited to fit 'struct nat_net' but 'struct synproxy_net' instead.
The latter is only 24 bytes on 64-bit systems, much smaller than struct
nat_net which is 176 bytes, perfectly explaining the OOB KASAN report.
Detect and handle a failed nf_nat_init() by testing the 'nf_nat_hook'
pointer which will be reset to NULL on initialization errors to prevent
the usage of an invalid nat_net pointer.
As this check is only needed when nf_nat.o is built-in, guard it by
'#ifndef MODULE...'.
Fixes: cbc1dd5b659f ("netfilter: nf_nat: Fix possible memory leak in nf_nat_init()")
Signed-off-by: Mathias Krause <minipli@grsecurity.net>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
---
net/netfilter/nf_nat_core.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/net/netfilter/nf_nat_core.c b/net/netfilter/nf_nat_core.c
index 2bbf5163c0e2..63ff6b4d5d21 100644
--- a/net/netfilter/nf_nat_core.c
+++ b/net/netfilter/nf_nat_core.c
@@ -1181,6 +1181,16 @@ int nf_nat_register_fn(struct net *net, u8 pf, const struct nf_hook_ops *ops,
struct nf_hook_ops *nat_ops;
int i, ret;
+#ifndef MODULE
+ /* If nf_nat_core is built-in and nf_nat_init() fails, dependent
+ * modules like nft_chain_nat.ko may still call this function.
+ * However, nat_net would be invalid, likely pointing to some other
+ * per-net structure.
+ */
+ if (WARN_ON_ONCE(!nf_nat_hook))
+ return -EOPNOTSUPP;
+#endif
+
if (WARN_ON_ONCE(pf >= ARRAY_SIZE(nat_net->nat_proto_net)))
return -EINVAL;
--
2.47.3
^ permalink raw reply related
* [PATCH net 02/14] netfilter: nf_conncount: prevent connlimit drops for early confirmed ct
From: Pablo Neira Ayuso @ 2026-06-23 22:15 UTC (permalink / raw)
To: netfilter-devel; +Cc: davem, netdev, kuba, pabeni, edumazet, fw, horms
In-Reply-To: <20260623221548.701545-1-pablo@netfilter.org>
From: Fernando Fernandez Mancera <fmancera@suse.de>
Commit 69894e5b4c5e ("netfilter: nft_connlimit: update the count if add
was skipped") introduced a regression where packets for valid
connections are dropped when using connlimit for soft-limiting
scenarios.
The issue occurs when a new connection reuses a socket currently in
the TIME_WAIT state. In this scenario, the connection tracking entry
is evaluated as already confirmed. Previously, __nf_conncount_add()
assumed that if a connection was confirmed and did not originate from
the loopback interface, it should skip the addition and return -EEXIST.
Skipping the addition triggers a garbage collection run that cleans up
the TIME_WAIT connection. Consequently, the active connection count
drops to 0, which xt_connlimit mishandles, leading to the false rejection
of the perfectly valid new connection.
Fix this by replacing the interface check with protocol-agnostic state
checks. We now skip the tree insertion and preserve the lockless garbage
collection optimization only if the connection is IPS_ASSURED. This
allows early-confirmed setup packets (such as reused TIME_WAIT sockets
or locally generated SYN-ACKs) to be properly evaluated and counted
without falsely dropping. The goto check_connections path is maintained
to ensure these setup packets are deduplicated correctly.
This has been tested with slowhttptest and HTTP server configured
locally to ensure we are not breaking soft-limiting scenarios for local
or external connections. In addition, it was tested with a OVS zone
limit too.
Fixes: 69894e5b4c5e ("netfilter: nft_connlimit: update the count if add was skipped")
Reported-by: Alejandro Olivan Alvarez <alejandro.olivan.alvarez@gmail.com>
Closes: https://lore.kernel.org/netfilter-devel/177349610461.3071718.4083978280323144323@eldamar.lan/
Signed-off-by: Fernando Fernandez Mancera <fmancera@suse.de>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
---
net/netfilter/nf_conncount.c | 11 +++++------
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/net/netfilter/nf_conncount.c b/net/netfilter/nf_conncount.c
index dd67004a5cc0..91582069f6d2 100644
--- a/net/netfilter/nf_conncount.c
+++ b/net/netfilter/nf_conncount.c
@@ -183,17 +183,16 @@ static int __nf_conncount_add(struct net *net,
return -ENOENT;
if (ct && nf_ct_is_confirmed(ct)) {
- /* local connections are confirmed in postrouting so confirmation
- * might have happened before hitting connlimit
+ /* Connection is confirmed but might still be in the setup phase.
+ * Only skip the tracking if it is fully assured. This guarantees
+ * that setup packets or retransmissions are properly counted and
+ * deduplicated.
*/
- if (skb->skb_iif != LOOPBACK_IFINDEX) {
+ if (test_bit(IPS_ASSURED_BIT, &ct->status)) {
err = -EEXIST;
goto out_put;
}
- /* this is likely a local connection, skip optimization to avoid
- * adding duplicates from a 'packet train'
- */
goto check_connections;
}
--
2.47.3
^ permalink raw reply related
* [PATCH net 03/14] netfilter: flowtable: Validate iph->ihl in nf_flow_ip4_tunnel_proto()
From: Pablo Neira Ayuso @ 2026-06-23 22:15 UTC (permalink / raw)
To: netfilter-devel; +Cc: davem, netdev, kuba, pabeni, edumazet, fw, horms
In-Reply-To: <20260623221548.701545-1-pablo@netfilter.org>
From: Lorenzo Bianconi <lorenzo@kernel.org>
Add sanity check for iph->ihl field in nf_flow_ip4_tunnel_proto() before
using it to compute the header size, avoiding out-of-bounds access with
malformed IP headers.
While at it, use iph->protocol instead of the hardcoded IPPROTO_IPIP
constant when setting ctx->tun.proto and reference ctx->tun.hdr_size
when updating ctx->offset.
Fixes: ab427db178858 ("netfilter: flowtable: Add IPIP rx sw acceleration")
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
---
net/netfilter/nf_flow_table_ip.c | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/net/netfilter/nf_flow_table_ip.c b/net/netfilter/nf_flow_table_ip.c
index e7a3fb2b2d94..29e93ac1e2e4 100644
--- a/net/netfilter/nf_flow_table_ip.c
+++ b/net/netfilter/nf_flow_table_ip.c
@@ -326,8 +326,10 @@ static bool nf_flow_ip4_tunnel_proto(struct nf_flowtable_ctx *ctx,
return false;
iph = (struct iphdr *)(skb_network_header(skb) + ctx->offset);
- size = iph->ihl << 2;
+ if (iph->ihl < 5)
+ return false;
+ size = iph->ihl << 2;
if (ip_is_fragment(iph) || unlikely(ip_has_options(size)))
return false;
@@ -335,9 +337,9 @@ static bool nf_flow_ip4_tunnel_proto(struct nf_flowtable_ctx *ctx,
return false;
if (iph->protocol == IPPROTO_IPIP) {
- ctx->tun.proto = IPPROTO_IPIP;
+ ctx->tun.proto = iph->protocol;
ctx->tun.hdr_size = size;
- ctx->offset += size;
+ ctx->offset += ctx->tun.hdr_size;
}
return true;
--
2.47.3
^ permalink raw reply related
* [PATCH net 04/14] netfilter: x_tables.h: fix all kernel-doc warnings
From: Pablo Neira Ayuso @ 2026-06-23 22:15 UTC (permalink / raw)
To: netfilter-devel; +Cc: davem, netdev, kuba, pabeni, edumazet, fw, horms
In-Reply-To: <20260623221548.701545-1-pablo@netfilter.org>
From: Randy Dunlap <rdunlap@infradead.org>
- use correct names in kernel-doc comments
- add missing struct members to kernel-doc comments
Warning: include/linux/netfilter/x_tables.h:41 struct member 'targinfo' not described in 'xt_action_param'
Warning: include/linux/netfilter/x_tables.h:41 Excess struct member 'targetinfo' description in 'xt_action_param'
Warning: include/linux/netfilter/x_tables.h:90 struct member 'family' not described in 'xt_mtchk_param'
Warning: include/linux/netfilter/x_tables.h:90 struct member 'nft_compat' not described in 'xt_mtchk_param'
Warning: include/linux/netfilter/x_tables.h:101 expecting prototype for struct xt_mdtor_param. Prototype was for struct xt_mtdtor_param instead
Warning: include/linux/netfilter/x_tables.h:121 struct member 'net' not described in 'xt_tgchk_param'
Warning: include/linux/netfilter/x_tables.h:121 struct member 'table' not described in 'xt_tgchk_param'
Warning: include/linux/netfilter/x_tables.h:121 struct member 'target' not described in 'xt_tgchk_param'
Warning: include/linux/netfilter/x_tables.h:121 struct member 'targinfo' not described in 'xt_tgchk_param'
Warning: include/linux/netfilter/x_tables.h:121 struct member 'hook_mask' not described in 'xt_tgchk_param'
Warning: include/linux/netfilter/x_tables.h:121 struct member 'family' not described in 'xt_tgchk_param'
Warning: include/linux/netfilter/x_tables.h:121 struct member 'nft_compat' not described in 'xt_tgchk_param'
Warning: include/linux/netfilter/x_tables.h:345 expecting prototype for xt_recseq(). Prototype was for DECLARE_PER_CPU() instead
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
---
include/linux/netfilter/x_tables.h | 29 +++++++++++++++++++++--------
1 file changed, 21 insertions(+), 8 deletions(-)
diff --git a/include/linux/netfilter/x_tables.h b/include/linux/netfilter/x_tables.h
index 20d70dddbe50..25062f4a0dd5 100644
--- a/include/linux/netfilter/x_tables.h
+++ b/include/linux/netfilter/x_tables.h
@@ -18,7 +18,7 @@
* @match: the match extension
* @target: the target extension
* @matchinfo: per-match data
- * @targetinfo: per-target data
+ * @targinfo: per-target data
* @state: pointer to hook state this packet came from
* @fragoff: packet is a fragment, this is the data offset
* @thoff: position of transport header relative to skb->data
@@ -77,7 +77,9 @@ static inline u_int8_t xt_family(const struct xt_action_param *par)
* @match: struct xt_match through which this function was invoked
* @matchinfo: per-match data
* @hook_mask: via which hooks the new rule is reachable
- * Other fields as above.
+ * @family: actual NFPROTO_* through which the function is invoked
+ * (helpful when match->family == NFPROTO_UNSPEC)
+ * @nft_compat: running from the nft compat layer if true
*/
struct xt_mtchk_param {
struct net *net;
@@ -91,8 +93,13 @@ struct xt_mtchk_param {
};
/**
- * struct xt_mdtor_param - match destructor parameters
- * Fields as above.
+ * struct xt_mtdtor_param - match destructor parameters
+ *
+ * @net: network namespace through which the check was invoked
+ * @match: struct xt_match through which this function was invoked
+ * @matchinfo: per-match data
+ * @family: actual NFPROTO_* through which the function is invoked
+ * (helpful when match->family == NFPROTO_UNSPEC)
*/
struct xt_mtdtor_param {
struct net *net;
@@ -105,10 +112,16 @@ struct xt_mtdtor_param {
* struct xt_tgchk_param - parameters for target extensions'
* checkentry functions
*
+ * @net: network namespace through which the check was invoked
+ * @table: table the rule is tried to be inserted into
* @entryinfo: the family-specific rule data
* (struct ipt_entry, ip6t_entry, arpt_entry, ebt_entry)
- *
- * Other fields see above.
+ * @target: the target extension
+ * @targinfo: per-target data
+ * @hook_mask: via which hooks the new rule is reachable
+ * @family: actual NFPROTO_* through which the function is invoked
+ * (helpful when match->family == NFPROTO_UNSPEC)
+ * @nft_compat: running from the nft compat layer if true
*/
struct xt_tgchk_param {
struct net *net;
@@ -336,9 +349,9 @@ struct xt_table_info *xt_alloc_table_info(unsigned int size);
void xt_free_table_info(struct xt_table_info *info);
/**
- * xt_recseq - recursive seqcount for netfilter use
+ * var xt_recseq - recursive seqcount for netfilter use
*
- * Packet processing changes the seqcount only if no recursion happened
+ * Packet processing changes the seqcount only if no recursion happened.
* get_counters() can use read_seqcount_begin()/read_seqcount_retry(),
* because we use the normal seqcount convention :
* Low order bit set to 1 if a writer is active.
--
2.47.3
^ permalink raw reply related
* [PATCH net 05/14] netfilter: nft_synproxy: stop bypassing the priv->info snapshot
From: Pablo Neira Ayuso @ 2026-06-23 22:15 UTC (permalink / raw)
To: netfilter-devel; +Cc: davem, netdev, kuba, pabeni, edumazet, fw, horms
In-Reply-To: <20260623221548.701545-1-pablo@netfilter.org>
From: Runyu Xiao <runyu.xiao@seu.edu.cn>
nft_synproxy_eval_v4() and nft_synproxy_eval_v6() already take a
whole-object READ_ONCE() snapshot of the shared priv->info state before
building the SYNACK reply, but nft_synproxy_tcp_options() still masks
opts->options with priv->info.options from the live shared object.
When a named synproxy object is updated concurrently with SYN traffic,
the eval path can then mix mss and timestamp handling from the local
snapshot with an options mask taken from a newer configuration, so one
SYNACK no longer reflects a coherent synproxy configuration.
Use info->options so nft_synproxy_tcp_options() stays on the same local
snapshot that the eval path already copied from priv->info.
Fixes: ee394f96ad75 ("netfilter: nft_synproxy: add synproxy stateful object support")
Signed-off-by: Runyu Xiao <runyu.xiao@seu.edu.cn>
Reviewed-by: Fernando Fernandez Mancera <fmancera@suse.de>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
---
net/netfilter/nft_synproxy.c | 9 ++++-----
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/net/netfilter/nft_synproxy.c b/net/netfilter/nft_synproxy.c
index 7641f249614c..9ed288c9d168 100644
--- a/net/netfilter/nft_synproxy.c
+++ b/net/netfilter/nft_synproxy.c
@@ -24,14 +24,13 @@ static const struct nla_policy nft_synproxy_policy[NFTA_SYNPROXY_MAX + 1] = {
static void nft_synproxy_tcp_options(struct synproxy_options *opts,
const struct tcphdr *tcp,
struct synproxy_net *snet,
- struct nf_synproxy_info *info,
- const struct nft_synproxy *priv)
+ struct nf_synproxy_info *info)
{
this_cpu_inc(snet->stats->syn_received);
if (tcp->ece && tcp->cwr)
opts->options |= NF_SYNPROXY_OPT_ECN;
- opts->options &= priv->info.options;
+ opts->options &= info->options;
opts->mss_encode = opts->mss_option;
opts->mss_option = info->mss;
if (opts->options & NF_SYNPROXY_OPT_TIMESTAMP)
@@ -56,7 +55,7 @@ static void nft_synproxy_eval_v4(const struct nft_synproxy *priv,
if (tcp->syn) {
/* Initial SYN from client */
- nft_synproxy_tcp_options(opts, tcp, snet, &info, priv);
+ nft_synproxy_tcp_options(opts, tcp, snet, &info);
synproxy_send_client_synack(net, skb, tcp, opts);
consume_skb(skb);
regs->verdict.code = NF_STOLEN;
@@ -87,7 +86,7 @@ static void nft_synproxy_eval_v6(const struct nft_synproxy *priv,
if (tcp->syn) {
/* Initial SYN from client */
- nft_synproxy_tcp_options(opts, tcp, snet, &info, priv);
+ nft_synproxy_tcp_options(opts, tcp, snet, &info);
synproxy_send_client_synack_ipv6(net, skb, tcp, opts);
consume_skb(skb);
regs->verdict.code = NF_STOLEN;
--
2.47.3
^ permalink raw reply related
* [PATCH net 06/14] selftests: netfilter: conntrack_sctp_collision.sh: Introduce SCTP INIT collision test
From: Pablo Neira Ayuso @ 2026-06-23 22:15 UTC (permalink / raw)
To: netfilter-devel; +Cc: davem, netdev, kuba, pabeni, edumazet, fw, horms
In-Reply-To: <20260623221548.701545-1-pablo@netfilter.org>
From: Yi Chen <yiche.cy@gmail.com>
The existing test covered a scenario where a delayed INIT_ACK chunk
updates the vtag in conntrack after the association has already been
established.
A similar issue can occur with a delayed SCTP INIT chunk.
Add a new simultaneous-open test case where the client's INIT is
delayed, allowing conntrack to establish the association based on
the server-initiated handshake.
When the stale INIT arrives later, it may get recorded and cause a
following INIT_ACK from the peer to be accepted instead of dropped.
This INIT_ACK overwrites the vtag in conntrack, causing subsequent
SCTP DATA chunks to be considered as invalid and then dropped by
nft rules matching on ct state invalid.
This test verifies such stale INIT chunks do not cause problems.
Signed-off-by: Yi Chen <yiche.cy@gmail.com>
Acked-by: Xin Long <lucien.xin@gmail.com>
Signed-off-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
---
.../net/netfilter/conntrack_sctp_collision.sh | 89 ++++++++++++++-----
1 file changed, 67 insertions(+), 22 deletions(-)
diff --git a/tools/testing/selftests/net/netfilter/conntrack_sctp_collision.sh b/tools/testing/selftests/net/netfilter/conntrack_sctp_collision.sh
index d860f7d9744b..7261975957ef 100755
--- a/tools/testing/selftests/net/netfilter/conntrack_sctp_collision.sh
+++ b/tools/testing/selftests/net/netfilter/conntrack_sctp_collision.sh
@@ -2,18 +2,32 @@
# SPDX-License-Identifier: GPL-2.0
#
# Testing For SCTP COLLISION SCENARIO as Below:
-#
+# 1. Stale INIT_ACK capture:
# 14:35:47.655279 IP CLIENT_IP.PORT > SERVER_IP.PORT: sctp (1) [INIT] [init tag: 2017837359]
# 14:35:48.353250 IP SERVER_IP.PORT > CLIENT_IP.PORT: sctp (1) [INIT] [init tag: 1187206187]
# 14:35:48.353275 IP CLIENT_IP.PORT > SERVER_IP.PORT: sctp (1) [INIT ACK] [init tag: 2017837359]
# 14:35:48.353283 IP SERVER_IP.PORT > CLIENT_IP.PORT: sctp (1) [COOKIE ECHO]
# 14:35:48.353977 IP CLIENT_IP.PORT > SERVER_IP.PORT: sctp (1) [COOKIE ACK]
# 14:35:48.855335 IP SERVER_IP.PORT > CLIENT_IP.PORT: sctp (1) [INIT ACK] [init tag: 164579970]
+# (Delayed)
+#
+# 2. Stale INIT capture:
+# 14:35:48.353250 IP SERVER_IP.PORT > CLIENT_IP.PORT: sctp (1) [INIT] [init tag: 1187206187]
+# 14:35:48.353275 IP CLIENT_IP.PORT > SERVER_IP.PORT: sctp (1) [INIT ACK] [init tag: 2017837359]
+# 14:35:48.353283 IP SERVER_IP.PORT > CLIENT_IP.PORT: sctp (1) [COOKIE ECHO]
+# 14:35:48.353977 IP CLIENT_IP.PORT > SERVER_IP.PORT: sctp (1) [COOKIE ACK]
+# 14:35:47.655279 IP CLIENT_IP.PORT > SERVER_IP.PORT: sctp (1) [INIT] [init tag: 2017837359]
+# (Delayed)
+# 14:35:48.855335 IP SERVER_IP.PORT > CLIENT_IP.PORT: sctp (1) [INIT ACK] [init tag: 164579970]
#
# TOPO: SERVER_NS (link0)<--->(link1) ROUTER_NS (link2)<--->(link3) CLIENT_NS
source lib.sh
+checktool "nft --version" "run test without nft"
+checktool "tc -h" "run test without tc"
+checktool "modprobe -q sctp" "load sctp module"
+
CLIENT_IP="198.51.200.1"
CLIENT_PORT=1234
@@ -24,7 +38,8 @@ CLIENT_GW="198.51.200.2"
SERVER_GW="198.51.100.2"
# setup the topo
-setup() {
+topo_setup() {
+ # setup_ns cleans up existing net namespaces first.
setup_ns CLIENT_NS SERVER_NS ROUTER_NS
ip -n "$SERVER_NS" link add link0 type veth peer name link1 netns "$ROUTER_NS"
ip -n "$CLIENT_NS" link add link3 type veth peer name link2 netns "$ROUTER_NS"
@@ -38,35 +53,53 @@ setup() {
ip -n "$ROUTER_NS" addr add $SERVER_GW/24 dev link1
ip -n "$ROUTER_NS" addr add $CLIENT_GW/24 dev link2
ip net exec "$ROUTER_NS" sysctl -wq net.ipv4.ip_forward=1
+ sysctl -wq net.netfilter.nf_log_all_netns=1
ip -n "$CLIENT_NS" link set link3 up
ip -n "$CLIENT_NS" addr add $CLIENT_IP/24 dev link3
ip -n "$CLIENT_NS" route add $SERVER_IP dev link3 via $CLIENT_GW
+}
+
+conf_delay()
+{
+ # simulate the delay on OVS upcall by setting up a delay for INIT_ACK/INIT with
+ local ns=$1
+ local link=$2
+ local chunk_type=$3
- # simulate the delay on OVS upcall by setting up a delay for INIT_ACK with
- # tc on $SERVER_NS side
- tc -n "$SERVER_NS" qdisc add dev link0 root handle 1: htb r2q 64
- tc -n "$SERVER_NS" class add dev link0 parent 1: classid 1:1 htb rate 100mbit
- tc -n "$SERVER_NS" filter add dev link0 parent 1: protocol ip u32 match ip protocol 132 \
- 0xff match u8 2 0xff at 32 flowid 1:1
- if ! tc -n "$SERVER_NS" qdisc add dev link0 parent 1:1 handle 10: netem delay 1200ms; then
+ # use a smaller number for assoc's max_retrans to reproduce the issue
+ ip net exec "$CLIENT_NS" sysctl -wq net.sctp.association_max_retrans=3
+
+ tc -n "$ns" qdisc add dev "$link" root handle 1: htb r2q 64
+ tc -n "$ns" class add dev "$link" parent 1: classid 1:1 htb rate 100mbit
+ tc -n "$ns" filter add dev "$link" parent 1: protocol ip \
+ u32 match ip protocol 132 0xff match u8 "$chunk_type" 0xff at 32 flowid 1:1
+ if ! tc -n "$ns" qdisc add dev "$link" parent 1:1 handle 10: netem delay 1200ms; then
echo "SKIP: Cannot add netem qdisc"
- exit $ksft_skip
+ return $ksft_skip
fi
# simulate the ctstate check on OVS nf_conntrack
- ip net exec "$ROUTER_NS" iptables -A FORWARD -m state --state INVALID,UNTRACKED -j DROP
- ip net exec "$ROUTER_NS" iptables -A INPUT -p sctp -j DROP
-
- # use a smaller number for assoc's max_retrans to reproduce the issue
- modprobe -q sctp
- ip net exec "$CLIENT_NS" sysctl -wq net.sctp.association_max_retrans=3
+ ip net exec "$ROUTER_NS" nft -f - <<-EOF
+ table ip t {
+ chain forward {
+ type filter hook forward priority filter; policy accept;
+ meta l4proto icmp counter accept
+ ct state new counter accept
+ ct state established,related counter accept
+ ct state invalid log flags all counter drop comment \
+ "Expect to drop stale INIT/INIT_ACK chunks"
+ counter
+ }
+ }
+ EOF
+ return 0
}
cleanup() {
- ip net exec "$CLIENT_NS" pkill sctp_collision >/dev/null 2>&1
- ip net exec "$SERVER_NS" pkill sctp_collision >/dev/null 2>&1
+ # cleanup_all_ns terminates running processes in the namespaces.
cleanup_all_ns
+ sysctl -wq net.netfilter.nf_log_all_netns=0
}
do_test() {
@@ -81,7 +114,19 @@ do_test() {
# run the test case
trap cleanup EXIT
-setup && \
-echo "Test for SCTP Collision in nf_conntrack:" && \
-do_test && echo "PASS!"
-exit $?
+
+echo "Test for SCTP INIT_ACK Collision in nf_conntrack:"
+topo_setup || exit $?
+conf_delay $SERVER_NS link0 2 || exit $?
+
+if ! do_test; then
+ exit $ksft_fail
+fi
+
+echo "Test for SCTP INIT Collision in nf_conntrack:"
+topo_setup || exit $?
+conf_delay $CLIENT_NS link3 1 || exit $?
+
+if ! do_test; then
+ exit $ksft_fail
+fi
--
2.47.3
^ permalink raw reply related
* [PATCH net 07/14] netfilter: nft_compat: ebtables emulation must reject non-bridge targets
From: Pablo Neira Ayuso @ 2026-06-23 22:15 UTC (permalink / raw)
To: netfilter-devel; +Cc: davem, netdev, kuba, pabeni, edumazet, fw, horms
In-Reply-To: <20260623221548.701545-1-pablo@netfilter.org>
From: Florian Westphal <fw@strlen.de>
xtables targets return netfilter verdicts: NF_ACCEPT, NF_DROP, and so
on. ebtables targets return incompatible verdicts: EBT_ACCEPT,
EBT_DROP, ... We cannot allow fallback to NFPROTO_UNSPEC.
ebtables doesn't permit this since
11ff7288beb2 ("netfilter: ebtables: reject non-bridge targets")
but that commit missed the nft_compat layer.
Reported-by: Ren Wei <n05ec@lzu.edu.cn>
Reported-by: Wyatt Feng <bronzed_45_vested@icloud.com>
Reported-by: Yuan Tan <yuantan098@gmail.com>
Reported-by: Yifan Wu <yifanwucs@gmail.com>
Reported-by: Juefei Pu <tomapufckgml@gmail.com>
Reported-by: Zhengchuan Liang <zcliangcn@gmail.com>
Reported-by: Xin Liu <bird@lzu.edu.cn>
Fixes: 0ca743a55991 ("netfilter: nf_tables: add compatibility layer for x_tables")
Signed-off-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
---
net/netfilter/nft_compat.c | 24 +++++++++++++++++++++---
1 file changed, 21 insertions(+), 3 deletions(-)
diff --git a/net/netfilter/nft_compat.c b/net/netfilter/nft_compat.c
index 0caa9304d2d0..63864b928259 100644
--- a/net/netfilter/nft_compat.c
+++ b/net/netfilter/nft_compat.c
@@ -397,6 +397,22 @@ static int nft_target_validate(const struct nft_ctx *ctx,
return 0;
}
+static int nft_target_bridge_validate(const struct nft_ctx *ctx,
+ const struct nft_expr *expr)
+{
+ struct xt_target *target = expr->ops->data;
+
+ /* Do not allow UNSPEC to stand-in for NFPROTO_BRIDGE
+ * targets: they are incompatible. ebtables targets return
+ * EBT_ACCEPT, DROP and so on which are not compatible with
+ * NF_ACCEPT, NF_DROP and so on.
+ */
+ if (target->family != NFPROTO_BRIDGE)
+ return -ENOENT;
+
+ return nft_target_validate(ctx, expr);
+}
+
static void __nft_match_eval(const struct nft_expr *expr,
struct nft_regs *regs,
const struct nft_pktinfo *pkt,
@@ -932,13 +948,15 @@ nft_target_select_ops(const struct nft_ctx *ctx,
ops->init = nft_target_init;
ops->destroy = nft_target_destroy;
ops->dump = nft_target_dump;
- ops->validate = nft_target_validate;
ops->data = target;
- if (family == NFPROTO_BRIDGE)
+ if (family == NFPROTO_BRIDGE) {
ops->eval = nft_target_eval_bridge;
- else
+ ops->validate = nft_target_bridge_validate;
+ } else {
ops->eval = nft_target_eval_xt;
+ ops->validate = nft_target_validate;
+ }
return ops;
err:
--
2.47.3
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox