* Re: [PATCH] gtp: disable BH before calling udp_tunnel_xmit_skb()
From: Justin Iurman @ 2026-04-20 19:02 UTC (permalink / raw)
To: David Carlier, Pablo Neira Ayuso, Harald Welte, Andrew Lunn,
Eric Dumazet, Jakub Kicinski, Paolo Abeni
Cc: Weiming Shi, osmocom-net-gprs, netdev, linux-kernel, stable
In-Reply-To: <20260417055408.4667-1-devnexen@gmail.com>
On 4/17/26 07:54, David Carlier wrote:
> gtp_genl_send_echo_req() runs as a generic netlink doit handler in
> process context with BH not disabled. It calls udp_tunnel_xmit_skb(),
> which eventually invokes iptunnel_xmit() — that uses __this_cpu_inc/dec
> on softnet_data.xmit.recursion to track the tunnel xmit recursion level.
>
> Without local_bh_disable(), the task may migrate between
> dev_xmit_recursion_inc() and dev_xmit_recursion_dec(), breaking the
> per-CPU counter pairing. The result is stale or negative recursion
> levels that can later produce false-positive
> SKB_DROP_REASON_RECURSION_LIMIT drops on either CPU.
>
> The other udp_tunnel_xmit_skb() call sites in gtp.c are unaffected:
> the data path runs under ndo_start_xmit and the echo response handlers
> run from the UDP encap rx softirq, both with BH already disabled.
>
> Fix it by disabling BH around the udp_tunnel_xmit_skb() call, mirroring
> commit 2cd7e6971fc2 ("sctp: disable BH before calling
> udp_tunnel_xmit_skb()").
Why not fix iptunnel_xmit() directly, rather than fixing all possible
callers? Basically, jut like we did for lwtunnel_{output|xmit}(). The
advantage would be that we no longer have to worry about BHs in the
callers, and BHs would only be disabled when necessary.
^ permalink raw reply
* AW: pre-boot plugged SFP autoneg advertisement
From: markus.stockhausen @ 2026-04-20 19:10 UTC (permalink / raw)
To: 'Andrew Lunn'
Cc: linux, hkallweit1, netdev, 'Jonas Jelonek', jan, nbd,
'Daniel Golle'
In-Reply-To: <664e6e24-4a94-43fa-8769-773a37a01c66@lunn.ch>
> Von: Andrew Lunn <andrew@lunn.ch>
> Gesendet: Montag, 20. April 2026 19:58
> An: markus.stockhausen@gmx.de
>
> > Sequence of events during boot is as follows:
> >
> > - SFP module is already inserted (in my case 1G)
> > - phylink_sfp_config_phy() runs long before any network config starts
> > - OpenWrt netifd daemon starts and wants to configure the network
interfaces
> > - It reads current settings via ethtool ioctl and gets autoneg=off
> > - It writes basic config values via ethtool ioctl including autneg=off
> > - Later on it starts the interface and phylink_start() is issued
>
> I would say netifd is not optimal. I'm not sure we every agree to
> return the full ksetting on an interface which is admin down. Many
> driver don't even connect to the PHY until open is called, and so are
> likely to return -ENODEV. See phy_ethtool_set_link_ksettings().
>
> Could you look into the behaviour of netifd, especially if it gets
> -ENODEV during the first read. Does it try again after setting the
> interface up?
Netifd has no issues with linksettings reading/writing in admin state.
Getting a rc=0 it assumes that all values are filled, changes the needed
attributes and writes them back. I retested and think there might be a
solution to avoid unneeded Ioctl access (see [1])
> If we know phylink is going to return a subset of the correct
> information when the interface is admin down, maybe it should return
> -ENODEV?
Or (stupid idea) phylink_ethtool_ksettings_set() should not accept all
settings in this state.
Thanks for your valuable input.
Markus
[1] https://github.com/openwrt/netifd/issues/76#issuecomment-4283478081
^ permalink raw reply
* Re: [PATCH net 1/1] net/rose: hold listener socket during call request handling
From: Yuan Tan @ 2026-04-20 19:11 UTC (permalink / raw)
To: Simon Horman, Ren Wei
Cc: yuantan098, linux-hams, netdev, davem, edumazet, kuba, pabeni,
kees, takamitz, kuniyu, jiayuan.chen, mingo, stanksal, jlayton,
yifanwucs, tomapufckgml, bird, tonanli66
In-Reply-To: <20260420162605.GV280379@horms.kernel.org>
On 4/20/2026 9:26 AM, Simon Horman wrote:
> On Fri, Apr 17, 2026 at 07:01:51PM +0800, Ren Wei wrote:
>> From: Nan Li <tonanli66@gmail.com>
>>
>> The call request receive path keeps using the listener socket after the
>> lookup lock has been dropped. Keep the listener alive across the
>> remaining validation and child socket setup by taking a reference in the
>> lookup path and releasing it once request handling is finished.
>>
>> This makes listener lifetime handling explicit and avoids races with
>> concurrent socket teardown.
>>
>> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
>> Cc: stable@kernel.org
>> Reported-by: Yifan Wu <yifanwucs@gmail.com>
>> Reported-by: Juefei Pu <tomapufckgml@gmail.com>
>> Reported-by: Xin Liu <bird@lzu.edu.cn>
>> Co-developed-by: Yuan Tan <yuantan098@gmail.com>
>> Signed-off-by: Yuan Tan <yuantan098@gmail.com>
>> Signed-off-by: Nan Li <tonanli66@gmail.com>
>> Signed-off-by: Ren Wei <n05ec@lzu.edu.cn>
>> ---
>> net/rose/af_rose.c | 24 +++++++++++++++++++-----
>> 1 file changed, 19 insertions(+), 5 deletions(-)
> Reviewed-by: Simon Horman <horms@kernel.org>
>
> Sachiko has provided some feedback on this patch.
> I do not believe they relate to shortcomings in this patch,
> and I do not believe they should block progress of this patch.
> You may want to look over them for areas to investigate as follow-up
> (maybe you already did :)
>
> ...
Thanks for your review! Yes this module still has other issues that
haven't been fixed. We'll finish what we're currently working on and
then take a look :)
^ permalink raw reply
* Re: [PATCH 1/2] Bluetooth: ISO: Fix data-race on dst in iso_sock_connect()
From: Luiz Augusto von Dentz @ 2026-04-20 19:23 UTC (permalink / raw)
To: SeungJu Cheon
Cc: marcel, linux-bluetooth, netdev, linux-kernel, me, skhan,
linux-kernel-mentees
In-Reply-To: <20260418053401.128483-2-suunj1331@gmail.com>
Hi SeungJu,
On Sat, Apr 18, 2026 at 1:34 AM SeungJu Cheon <suunj1331@gmail.com> wrote:
>
> iso_sock_connect() copies the destination address into
> iso_pi(sk)->dst under lock_sock, then releases the lock and reads
> it back with bacmp() to decide between the CIS and BIS connect
> paths:
>
> lock_sock(sk);
> bacpy(&iso_pi(sk)->dst, &sa->iso_bdaddr);
> iso_pi(sk)->dst_type = sa->iso_bdaddr_type;
> release_sock(sk);
>
> if (bacmp(&iso_pi(sk)->dst, BDADDR_ANY)) // <- no lock held
>
> This read after release_sock() races with any concurrent write to
> iso_pi(sk)->dst on the same socket.
>
> Fix by performing the bacmp() inside the lock_sock critical section
> and caching the result in a local variable.
>
> This patch addresses only the bacmp() race in iso_sock_connect();
> other unprotected iso_pi(sk) accesses are fixed separately in the
> next patch.
>
> KCSAN report:
>
> BUG: KCSAN: data-race in memcmp+0x39/0xb0
>
> race at unknown origin, with read to 0xffff8f96ea66dde3 of 1 bytes by task 549 on cpu 1:
> memcmp+0x39/0xb0
> iso_sock_connect+0x275/0xb40
> __sys_connect_file+0xbd/0xe0
> __sys_connect+0xe0/0x110
> __x64_sys_connect+0x40/0x50
> x64_sys_call+0xcad/0x1c60
> do_syscall_64+0x133/0x590
> entry_SYSCALL_64_after_hwframe+0x77/0x7f
>
> value changed: 0x00 -> 0xee
>
> Reported by Kernel Concurrency Sanitizer on:
> CPU: 1 UID: 0 PID: 549 Comm: iso_race_combin Not tainted 7.0.0-08391-g1d51b370a0f8 #40 PREEMPT(lazy)
>
> Fixes: ccf74f2390d6 ("Bluetooth: Add BTPROTO_ISO socket type")
> Signed-off-by: SeungJu Cheon <suunj1331@gmail.com>
> ---
> net/bluetooth/iso.c | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/net/bluetooth/iso.c b/net/bluetooth/iso.c
> index be145e2736b7..14963ba68597 100644
> --- a/net/bluetooth/iso.c
> +++ b/net/bluetooth/iso.c
> @@ -1169,6 +1169,7 @@ static int iso_sock_connect(struct socket *sock, struct sockaddr_unsized *addr,
> struct sockaddr_iso *sa = (struct sockaddr_iso *)addr;
> struct sock *sk = sock->sk;
> int err;
> + bool bcast;
>
> BT_DBG("sk %p", sk);
>
> @@ -1191,9 +1192,11 @@ static int iso_sock_connect(struct socket *sock, struct sockaddr_unsized *addr,
> bacpy(&iso_pi(sk)->dst, &sa->iso_bdaddr);
> iso_pi(sk)->dst_type = sa->iso_bdaddr_type;
>
> + bcast = !bacmp(&iso_pi(sk)->dst, BDADDR_ANY);
> +
> release_sock(sk);
>
> - if (bacmp(&iso_pi(sk)->dst, BDADDR_ANY))
> + if (!bcast)
> err = iso_connect_cis(sk);
> else
> err = iso_connect_bis(sk);
> --
> 2.52.0
>
https://sashiko.dev/#/patchset/20260418053401.128483-1-suunj1331%40gmail.com
Seems valid, so we migth just use sa in the place of iso_pi(sk) to
avoid using it without sk being locked. Other problems it may reveal
need to be addressed in separate patches.
--
Luiz Augusto von Dentz
^ permalink raw reply
* [PATCH net] ipv4: clamp MCAST_MSFILTER getsockopt to optlen, not gf_numsrc
From: Greg Kroah-Hartman @ 2026-04-20 19:26 UTC (permalink / raw)
To: netdev
Cc: linux-kernel, Greg Kroah-Hartman, David S. Miller, David Ahern,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Simon Horman, stable
ip_get_mcast_msfilter() and its compat sibling read gf_numsrc from
the user's buffer header and pass it to ip_mc_gsfget(), which writes:
min(actual_sources, gf_numsrc) * sizeof(struct sockaddr_storage)
bytes back into the user's optval starting at the gf_slist_flex offset.
The only optlen check is len >= size0 (the header), so a user can pass
optlen = 144 (header only) with gf_numsrc = 4. If the socket has at
least 4 sources joined, the kernel writes 4*128 = 512 bytes via
copy_to_sockptr_offset() past the end of the user buffer.
This is a kernel-driven userspace heap overflow: the user told the
kernel their buffer size via optlen, the kernel ignored it and used a
field inside the buffer instead. On a real system the writes go into
adjacent userspace heap and copy_to_user does not fault on mapped heap
pages.
Clamp gf_numsrc to (len - size0) / sizeof(sockaddr_storage) before the
call so the kernel never writes past what the user provided. The
setsockopt path already has the equivalent check
(GROUP_FILTER_SIZE(gf_numsrc) > optlen at line 790).
Cc: "David S. Miller" <davem@davemloft.net>
Cc: David Ahern <dsahern@kernel.org>
Cc: Eric Dumazet <edumazet@google.com>
Cc: Jakub Kicinski <kuba@kernel.org>
Cc: Paolo Abeni <pabeni@redhat.com>
Cc: Simon Horman <horms@kernel.org>
Reported-by: Anthropic
Assisted-by: gkh_clanker_t1000
Cc: stable <stable@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/ipv4/ip_sockglue.c | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/net/ipv4/ip_sockglue.c b/net/ipv4/ip_sockglue.c
index a55ef327ec93..c9bf5d223f21 100644
--- a/net/ipv4/ip_sockglue.c
+++ b/net/ipv4/ip_sockglue.c
@@ -1456,6 +1456,11 @@ static int ip_get_mcast_msfilter(struct sock *sk, sockptr_t optval,
return -EFAULT;
num = gsf.gf_numsrc;
+
+ if (num > (len - size0) / sizeof(struct sockaddr_storage))
+ num = (len - size0) / sizeof(struct sockaddr_storage);
+ gsf.gf_numsrc = num;
+
err = ip_mc_gsfget(sk, &gsf, optval,
offsetof(struct group_filter, gf_slist_flex));
if (err)
@@ -1486,8 +1491,12 @@ static int compat_ip_get_mcast_msfilter(struct sock *sk, sockptr_t optval,
gf.gf_interface = gf32.gf_interface;
gf.gf_fmode = gf32.gf_fmode;
num = gf.gf_numsrc = gf32.gf_numsrc;
- gf.gf_group = gf32.gf_group;
+ if (num > (len - size0) / sizeof(struct sockaddr_storage))
+ num = (len - size0) / sizeof(struct sockaddr_storage);
+ gf.gf_numsrc = num;
+
+ gf.gf_group = gf32.gf_group;
err = ip_mc_gsfget(sk, &gf, optval,
offsetof(struct compat_group_filter, gf_slist_flex));
if (err)
--
2.53.0
^ permalink raw reply related
* [PATCH net] ipv6: rpl: expand skb head when recompressed SRH grows, not only on last segment
From: Greg Kroah-Hartman @ 2026-04-20 19:32 UTC (permalink / raw)
To: netdev
Cc: linux-kernel, Greg Kroah-Hartman, David S. Miller, David Ahern,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Simon Horman, stable
ipv6_rpl_srh_rcv() processes a Routing Protocol for LLNs Source Routing
Header by decompressing it, swapping the next segment address into
ipv6_hdr->daddr, recompressing, and pushing the new header back. The
recompressed header can be larger than the original when the
address-elision opportunities are worse after the swap.
The function pulls (hdr->hdrlen + 1) << 3 bytes (the old header) and
pushes (chdr->hdrlen + 1) << 3 + sizeof(ipv6hdr) bytes (the new header
plus the IPv6 header). pskb_expand_head() is called to guarantee
headroom only when segments_left == 0.
A crafted SRH that loops back to the local host (each segment is a local
address, so ip6_route_input() delivers it back to ipv6_rpl_srh_rcv())
with chdr growing on each pass exhausts headroom over several
iterations. When skb_push() lands skb->data exactly at skb->head,
skb_reset_network_header() stores 0, and skb_mac_header_rebuild()'s
skb_set_mac_header(skb, -skb->mac_len) computes 0 + (u16)(-14) = 65522.
The subsequent memmove writes 14 bytes at skb->head + 65522.
Expand the head whenever there is insufficient room for the push, not
only on the final segment.
Cc: "David S. Miller" <davem@davemloft.net>
Cc: David Ahern <dsahern@kernel.org>
Cc: Eric Dumazet <edumazet@google.com>
Cc: Jakub Kicinski <kuba@kernel.org>
Cc: Paolo Abeni <pabeni@redhat.com>
Cc: Simon Horman <horms@kernel.org>
Reported-by: Anthropic
Cc: stable <stable@kernel.org>
Assisted-by: gkh_clanker_t1000
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/ipv6/exthdrs.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/net/ipv6/exthdrs.c b/net/ipv6/exthdrs.c
index 95558fd6f447..d866ab011e0a 100644
--- a/net/ipv6/exthdrs.c
+++ b/net/ipv6/exthdrs.c
@@ -592,7 +592,9 @@ static int ipv6_rpl_srh_rcv(struct sk_buff *skb)
skb_pull(skb, ((hdr->hdrlen + 1) << 3));
skb_postpull_rcsum(skb, oldhdr,
sizeof(struct ipv6hdr) + ((hdr->hdrlen + 1) << 3));
- if (unlikely(!hdr->segments_left)) {
+ if (unlikely(!hdr->segments_left ||
+ skb_headroom(skb) < sizeof(struct ipv6hdr) +
+ ((chdr->hdrlen + 1) << 3))) {
if (pskb_expand_head(skb, sizeof(struct ipv6hdr) + ((chdr->hdrlen + 1) << 3), 0,
GFP_ATOMIC)) {
__IP6_INC_STATS(net, ip6_dst_idev(skb_dst(skb)), IPSTATS_MIB_OUTDISCARDS);
--
2.53.0
^ permalink raw reply related
* Re: [PATCH net v2 1/8] xsk: reject sw-csum UMEM binding to IFF_TX_SKB_NO_LINEAR devices
From: Stanislav Fomichev @ 2026-04-20 19:34 UTC (permalink / raw)
To: Jason Xing; +Cc: bpf, netdev, Jason Xing
In-Reply-To: <20260420082805.14844-2-kerneljasonxing@gmail.com>
> From: Jason Xing <kernelxing@tencent.com>
>
> skb_checksum_help() is a common helper that writes the folded
> 16-bit checksum back via skb->data + csum_start + csum_offset,
> i.e. it relies on the skb's linear head and fails (with WARN_ONCE
> and -EINVAL) when skb_headlen() is 0.
>
> AF_XDP generic xmit takes two very different paths depending on the
> netdev. Drivers that advertise IFF_TX_SKB_NO_LINEAR (e.g. virtio_net)
> skip the "copy payload into a linear head" step on purpose as a
> performance optimisation: xsk_build_skb_zerocopy() only attaches UMEM
> pages as frags and never calls skb_put(), so skb_headlen() stays 0
> for the whole skb. For these skbs there is simply no linear area for
> skb_checksum_help() to write the csum into - the sw-csum fallback is
> structurally inapplicable.
>
> The patch tries to catch this and reject the combination with error at
> setup time. Rejecting at bind() converts this silent per-packet failure
> into a synchronous, actionable -EOPNOTSUPP at setup time. HW csum and
> launch_time metadata on IFF_TX_SKB_NO_LINEAR drivers are unaffected
> because they do not call skb_checksum_help().
>
> Without the patch, every descriptor carrying 'XDP_TX_METADATA |
> XDP_TXMD_FLAGS_CHECKSUM' produces:
> 1) a WARN_ONCE "offset (N) >= skb_headlen() (0)" from skb_checksum_help(),
> 2) sendmsg() returning -EINVAL without consuming the descriptor
> (invalid_descs is not incremented),
> 3) a wedged TX ring: __xsk_generic_xmit() does not advance the
> consumer on non-EOVERFLOW errors, so the next sendmsg() re-reads
> the same descriptor and re-hits the same WARN until the socket
> is closed.
>
> Closes: https://lore.kernel.org/all/20260419045822.843BFC2BCAF@smtp.kernel.org/#t
> Fixes: 30c3055f9c0d ("xsk: wrap generic metadata handling onto separate function")
> Signed-off-by: Jason Xing <kernelxing@tencent.com>
> ---
> net/xdp/xsk_buff_pool.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/net/xdp/xsk_buff_pool.c b/net/xdp/xsk_buff_pool.c
> index 37b7a68b89b3..c2521b6547e3 100644
> --- a/net/xdp/xsk_buff_pool.c
> +++ b/net/xdp/xsk_buff_pool.c
> @@ -169,6 +169,9 @@ int xp_assign_dev(struct xsk_buff_pool *pool,
> if (force_zc && force_copy)
> return -EINVAL;
>
> + if (pool->tx_sw_csum && (netdev->priv_flags & IFF_TX_SKB_NO_LINEAR))
> + return -EOPNOTSUPP;
> +
> if (xsk_get_pool_from_qid(netdev, queue_id))
> return -EBUSY;
>
> --
> 2.41.3
>
Wondering whether a better fixes tag is commit 11614723af26 ("xsk: Add option
to calculate TX checksum in SW")?
Acked-by: Stanislav Fomichev <sdf@fomichev.me>
^ permalink raw reply
* Re: [PATCH net v2 2/8] xsk: handle NULL dereference of the skb without frags issue
From: Stanislav Fomichev @ 2026-04-20 19:34 UTC (permalink / raw)
To: Jason Xing; +Cc: bpf, netdev, Jason Xing
In-Reply-To: <20260420082805.14844-3-kerneljasonxing@gmail.com>
> From: Jason Xing <kernelxing@tencent.com>
>
> When a first descriptor (xs->skb == NULL) triggers -EOVERFLOW in
> xsk_build_skb_zerocopy (e.g., MAX_SKB_FRAGS exceeded), the free_err
> EOVERFLOW handler unconditionally dereferences xs->skb via
> xsk_inc_num_desc(xs->skb) and xsk_drop_skb(xs->skb), causing a NULL
> pointer dereference.
>
> In this series, the skb is already freed by kfree_skb() inside
> xsk_build_skb_zerocopy for the first-descriptor case, so we only need
> to do the bookkeeping: cancel the one reserved CQ slot and account for
> the single invalid descriptor.
>
> Guard the existing xsk_inc_num_desc/xsk_drop_skb calls with an
> xs->skb check (for the continuation case), and add an else branch
> for the first-descriptor case that manually cancels the CQ slot and
> increments invalid_descs by one.
>
> Fixes: cf24f5a5feea ("xsk: add support for AF_XDP multi-buffer on Tx path")
> Signed-off-by: Jason Xing <kernelxing@tencent.com>
> ---
> net/xdp/xsk.c | 11 ++++++++---
> 1 file changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/net/xdp/xsk.c b/net/xdp/xsk.c
> index 6149f6a79897..6521604f8d42 100644
> --- a/net/xdp/xsk.c
> +++ b/net/xdp/xsk.c
> @@ -893,9 +893,14 @@ static struct sk_buff *xsk_build_skb(struct xdp_sock *xs,
> kfree_skb(skb);
>
> if (err == -EOVERFLOW) {
> - /* Drop the packet */
> - xsk_inc_num_desc(xs->skb);
> - xsk_drop_skb(xs->skb);
> + if (xs->skb) {
> + /* Drop the packet */
> + xsk_inc_num_desc(xs->skb);
> + xsk_drop_skb(xs->skb);
> + } else {
> + xsk_cq_cancel_locked(xs->pool, 1);
> + xs->tx->invalid_descs++;
> + }
> xskq_cons_release(xs->tx);
> } else {
> /* Let application retry */
> --
> 2.41.3
>
Acked-by: Stanislav Fomichev <sdf@fomichev.me>
^ permalink raw reply
* Re: [PATCH net v2 3/8] xsk: fix use-after-free of xs->skb in xsk_build_skb() free_err path
From: Stanislav Fomichev @ 2026-04-20 19:34 UTC (permalink / raw)
To: Jason Xing; +Cc: bpf, netdev, Jason Xing
In-Reply-To: <20260420082805.14844-4-kerneljasonxing@gmail.com>
> From: Jason Xing <kernelxing@tencent.com>
>
> When xsk_build_skb() processes multi-buffer packets in copy mode, the
> first descriptor stores data into the skb linear area without adding
> any frags, so nr_frags stays at 0. The caller then sets xs->skb = skb
> to accumulate subsequent descriptors.
>
> If a continuation descriptor fails (e.g. alloc_page returns NULL with
> -EAGAIN), we jump to free_err where the condition:
>
> if (skb && !skb_shinfo(skb)->nr_frags)
> kfree_skb(skb);
>
> evaluates to true because nr_frags is still 0 (the first descriptor
> used the linear area, not frags). This frees the skb while xs->skb
> still points to it, creating a dangling pointer. On the next transmit
> attempt or socket close, xs->skb is dereferenced, causing a
> use-after-free or double-free.
>
> Fix by adding a !xs->skb check to the condition, ensuring we only free
> skbs that were freshly allocated in this call (xs->skb is NULL) and
> never free an in-progress multi-buffer skb that the caller still
> references.
>
> Closes: https://lore.kernel.org/all/20260415082654.21026-4-kerneljasonxing@gmail.com/
> Fixes: 6b9c129c2f93 ("xsk: remove @first_frag from xsk_build_skb()")
> Signed-off-by: Jason Xing <kernelxing@tencent.com>
> ---
> net/xdp/xsk.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/net/xdp/xsk.c b/net/xdp/xsk.c
> index 6521604f8d42..4fdd1a45a9bd 100644
> --- a/net/xdp/xsk.c
> +++ b/net/xdp/xsk.c
> @@ -889,7 +889,7 @@ static struct sk_buff *xsk_build_skb(struct xdp_sock *xs,
> return skb;
>
> free_err:
> - if (skb && !skb_shinfo(skb)->nr_frags)
> + if (skb && !xs->skb && !skb_shinfo(skb)->nr_frags)
> kfree_skb(skb);
>
> if (err == -EOVERFLOW) {
> --
> 2.41.3
Now "!skb_shinfo(skb)->nr_frags" feels redundant? It's either
"skb && !xs->skb" and we own the kfree. or "xs->skb != NULL" and we
want xsk_drop_skb? Or am I missing something?
^ permalink raw reply
* Re: [PATCH net v2 4/8] xsk: prevent CQ desync when freeing half-built skbs in xsk_build_skb()
From: Stanislav Fomichev @ 2026-04-20 19:34 UTC (permalink / raw)
To: Jason Xing; +Cc: bpf, netdev, Jason Xing
In-Reply-To: <20260420082805.14844-5-kerneljasonxing@gmail.com>
> From: Jason Xing <kernelxing@tencent.com>
>
> Once xsk_skb_init_misc() has been called on an skb, its destructor is
> set to xsk_destruct_skb(), which submits the descriptor address(es) to
> the completion queue and advances the CQ producer. If such an skb is
> subsequently freed via kfree_skb() along an error path - before the
> skb has ever been handed to the driver - the destructor still runs and
> submits a bogus, half-initialized address to the CQ.
>
> Introduce a new common helper to fix the issue. That function will be
> used by the subsequent patches soon.
>
> Closes: https://lore.kernel.org/all/20260419045822.843BFC2BCAF@smtp.kernel.org/
> Fixes: c30d084960cf ("xsk: avoid overwriting skb fields for multi-buffer traffic")
> Signed-off-by: Jason Xing <kernelxing@tencent.com>
> ---
> net/xdp/xsk.c | 8 +++++++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/net/xdp/xsk.c b/net/xdp/xsk.c
> index 4fdd1a45a9bd..614e7bd1252b 100644
> --- a/net/xdp/xsk.c
> +++ b/net/xdp/xsk.c
> @@ -717,6 +717,12 @@ static int xsk_skb_metadata(struct sk_buff *skb, void *buffer,
> return 0;
> }
>
> +static void xsk_drop_untrans_skb(struct sk_buff *skb)
> +{
> + skb->destructor = sock_wfree;
> + kfree_skb(skb);
> +}
> +
> static struct sk_buff *xsk_build_skb_zerocopy(struct xdp_sock *xs,
> struct xdp_desc *desc)
> {
> @@ -890,7 +896,7 @@ static struct sk_buff *xsk_build_skb(struct xdp_sock *xs,
>
> free_err:
> if (skb && !xs->skb && !skb_shinfo(skb)->nr_frags)
> - kfree_skb(skb);
> + xsk_drop_untrans_skb(skb);
>
> if (err == -EOVERFLOW) {
> if (xs->skb) {
> --
> 2.41.3
>
Have you considered the alternative where we postpone `skb->destructor =
xsk_destruct_skb` to a later point? Will this be less messy than
undoing that descriptor in a few curated places?
^ permalink raw reply
* Re: [PATCH net v2 11/12] idpf: fix xdp crash in soft reset error path
From: Jacob Keller @ 2026-04-20 19:41 UTC (permalink / raw)
To: Jakub Kicinski
Cc: andrew+netdev, davem, edumazet, pabeni, netdev, emil.s.tantilov,
stable, aleksandr.loktionov, patryk.holda
In-Reply-To: <20260418190019.194263-2-kuba@kernel.org>
On 4/18/2026 12:00 PM, Jakub Kicinski wrote:
> This is an AI-generated review of your patch. The human sending this
> email has considered the AI review valid, or at least plausible.
>
> Jakub: I'll drop this patch and apply the rest.
Thanks. Emil is on vacation, so I don't know if we'll get any response
for this fix for a bit. I'll forward this to others on the team and see
what they think.
Regards,
Jake
^ permalink raw reply
* Re: [PATCH v5 2/6] bpf: refactor masks for ADJ_ROOM flags and encap validation
From: Willem de Bruijn @ 2026-04-20 19:42 UTC (permalink / raw)
To: Nick Hudson, bpf, netdev, Willem de Bruijn, Martin KaFai Lau
Cc: Nick Hudson, Max Tottenham, Anna Glasgall, Daniel Borkmann,
Alexei Starovoitov, Andrii Nakryiko, Eduard Zingerman,
Kumar Kartikeya Dwivedi, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, linux-kernel
In-Reply-To: <20260420104051.1528843-3-nhudson@akamai.com>
Nick Hudson wrote:
> Refactor the helper masks for bpf_skb_adjust_room() flags to simplify
> validation logic and introduce:
>
> - BPF_F_ADJ_ROOM_ENCAP_MASK
> - BPF_F_ADJ_ROOM_DECAP_MASK
>
> Refactor existing validation checks in bpf_skb_net_shrink()
> and bpf_skb_adjust_room() to use the new masks (no behavior change).
>
> This is in preparation for supporting the new decap flags.
>
> Co-developed-by: Max Tottenham <mtottenh@akamai.com>
> Signed-off-by: Max Tottenham <mtottenh@akamai.com>
> Co-developed-by: Anna Glasgall <aglasgal@akamai.com>
> Signed-off-by: Anna Glasgall <aglasgal@akamai.com>
> Signed-off-by: Nick Hudson <nhudson@akamai.com>
Reviewed-by: Willem de Bruijn <willemb@google.com>
^ permalink raw reply
* Re: [PATCH v5 3/6] bpf: add BPF_F_ADJ_ROOM_DECAP_* flags for tunnel decapsulation
From: Willem de Bruijn @ 2026-04-20 19:44 UTC (permalink / raw)
To: Nick Hudson, bpf, netdev, Willem de Bruijn, Martin KaFai Lau
Cc: Nick Hudson, Max Tottenham, Anna Glasgall, Alexei Starovoitov,
Daniel Borkmann, Andrii Nakryiko, Eduard Zingerman,
Kumar Kartikeya Dwivedi, linux-kernel
In-Reply-To: <20260420104051.1528843-4-nhudson@akamai.com>
Nick Hudson wrote:
> Add new bpf_skb_adjust_room() decapsulation flags:
>
> - BPF_F_ADJ_ROOM_DECAP_L4_GRE
> - BPF_F_ADJ_ROOM_DECAP_L4_UDP
> - BPF_F_ADJ_ROOM_DECAP_IPXIP4
> - BPF_F_ADJ_ROOM_DECAP_IPXIP6
>
> These flags let BPF programs describe which tunnel layer is being
> removed, so later changes can update tunnel-related GSO state
> accordingly during decapsulation.
>
> This patch only introduces the UAPI flag definitions and helper
> documentation.
>
> Co-developed-by: Max Tottenham <mtottenh@akamai.com>
> Signed-off-by: Max Tottenham <mtottenh@akamai.com>
> Co-developed-by: Anna Glasgall <aglasgal@akamai.com>
> Signed-off-by: Anna Glasgall <aglasgal@akamai.com>
> Signed-off-by: Nick Hudson <nhudson@akamai.com>
Reviewed-by: Willem de Bruijn <willemb@google.com>
^ permalink raw reply
* Re: [PATCH] gtp: disable BH before calling udp_tunnel_xmit_skb()
From: David CARLIER @ 2026-04-20 19:44 UTC (permalink / raw)
To: Justin Iurman
Cc: Pablo Neira Ayuso, Harald Welte, Andrew Lunn, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Weiming Shi, osmocom-net-gprs,
netdev, linux-kernel, stable
In-Reply-To: <b44de581-9f41-4804-afb1-72c491d9443a@gmail.com>
Hi Julian,
On Mon, 20 Apr 2026 at 20:02, Justin Iurman <justin.iurman@gmail.com> wrote:
>
> On 4/17/26 07:54, David Carlier wrote:
> > gtp_genl_send_echo_req() runs as a generic netlink doit handler in
> > process context with BH not disabled. It calls udp_tunnel_xmit_skb(),
> > which eventually invokes iptunnel_xmit() — that uses __this_cpu_inc/dec
> > on softnet_data.xmit.recursion to track the tunnel xmit recursion level.
> >
> > Without local_bh_disable(), the task may migrate between
> > dev_xmit_recursion_inc() and dev_xmit_recursion_dec(), breaking the
> > per-CPU counter pairing. The result is stale or negative recursion
> > levels that can later produce false-positive
> > SKB_DROP_REASON_RECURSION_LIMIT drops on either CPU.
> >
> > The other udp_tunnel_xmit_skb() call sites in gtp.c are unaffected:
> > the data path runs under ndo_start_xmit and the echo response handlers
> > run from the UDP encap rx softirq, both with BH already disabled.
> >
> > Fix it by disabling BH around the udp_tunnel_xmit_skb() call, mirroring
> > commit 2cd7e6971fc2 ("sctp: disable BH before calling
> > udp_tunnel_xmit_skb()").
>
> Why not fix iptunnel_xmit() directly, rather than fixing all possible
> callers? Basically, jut like we did for lwtunnel_{output|xmit}(). The
> advantage would be that we no longer have to worry about BHs in the
> callers, and BHs would only be disabled when necessary.
Good point — your lwtunnel fix (c03a49f3093a) is a close parallel, and
a central fix would avoid chasing callers one by one (sctp was patched
last week, gtp is this one, and tipc/wireguard/ovpn genl paths look
similar).
Happy to respin as v2 with local_bh_disable/enable moved into
iptunnel_xmit() (and ip6tunnel_xmit() for symmetry), and drop the
gtp-local hunk. That would also supersede Xin Long's recent sctp
commit
(2cd7e6971fc2), so I'll make sure to Cc him.
One thing I'd like your take on before I send: iptunnel_xmit() feels
like the natural home since it owns the recursion counter, but would
you rather see it in udp_tunnel_xmit_skb()? I don't want to pick the
wrong spot if you already have a preference.
Cheers !
^ permalink raw reply
* Re: [PATCH v5 4/6] bpf: allow new DECAP flags and add guard rails
From: Willem de Bruijn @ 2026-04-20 19:45 UTC (permalink / raw)
To: Nick Hudson, bpf, netdev, Willem de Bruijn, Martin KaFai Lau
Cc: Nick Hudson, Max Tottenham, Anna Glasgall, Alexei Starovoitov,
Daniel Borkmann, Andrii Nakryiko, Eduard Zingerman,
Kumar Kartikeya Dwivedi, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, linux-kernel
In-Reply-To: <20260420104051.1528843-5-nhudson@akamai.com>
Nick Hudson wrote:
> Add checks to require shrink-only decap, reject conflicting decap flag
> combinations, and verify removed length is sufficient for claimed header
> decapsulation.
>
> Co-developed-by: Max Tottenham <mtottenh@akamai.com>
> Signed-off-by: Max Tottenham <mtottenh@akamai.com>
> Co-developed-by: Anna Glasgall <aglasgal@akamai.com>
> Signed-off-by: Anna Glasgall <aglasgal@akamai.com>
> Signed-off-by: Nick Hudson <nhudson@akamai.com>
Reviewed-by: Willem de Bruijn <willemb@google.com>
^ permalink raw reply
* Re: [PATCH v5 5/6] bpf: clear decap tunnel GSO state in skb_adjust_room
From: Willem de Bruijn @ 2026-04-20 19:46 UTC (permalink / raw)
To: Nick Hudson, bpf, netdev, Willem de Bruijn, Martin KaFai Lau
Cc: Nick Hudson, Max Tottenham, Anna Glasgall, Alexei Starovoitov,
Daniel Borkmann, Andrii Nakryiko, Eduard Zingerman,
Kumar Kartikeya Dwivedi, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, linux-kernel
In-Reply-To: <20260420104051.1528843-6-nhudson@akamai.com>
Nick Hudson wrote:
> On shrink in bpf_skb_adjust_room(), clear tunnel-specific GSO flags
> according to the decapsulation flags:
>
> - BPF_F_ADJ_ROOM_DECAP_L4_UDP clears SKB_GSO_UDP_TUNNEL{,_CSUM}
> - BPF_F_ADJ_ROOM_DECAP_L4_GRE clears SKB_GSO_GRE{,_CSUM}
> - BPF_F_ADJ_ROOM_DECAP_IPXIP4 clears SKB_GSO_IPXIP4
> - BPF_F_ADJ_ROOM_DECAP_IPXIP6 clears SKB_GSO_IPXIP6
>
> When all tunnel-related GSO bits are cleared, also clear
> skb->encapsulation.
>
> Handle the ESP inside a UDP tunnel case where encapsulation should remain
> set.
>
> Co-developed-by: Max Tottenham <mtottenh@akamai.com>
> Signed-off-by: Max Tottenham <mtottenh@akamai.com>
> Co-developed-by: Anna Glasgall <aglasgal@akamai.com>
> Signed-off-by: Anna Glasgall <aglasgal@akamai.com>
> Signed-off-by: Nick Hudson <nhudson@akamai.com>
Reviewed-by: Willem de Bruijn <willemb@google.com>
^ permalink raw reply
* Re: [PATCH net v2 11/12] idpf: fix xdp crash in soft reset error path
From: Jacob Keller @ 2026-04-20 19:48 UTC (permalink / raw)
To: Joshua Hay
Cc: andrew+netdev, davem, edumazet, pabeni, netdev, emil.s.tantilov,
stable, aleksandr.loktionov, patryk.holda
In-Reply-To: <20260418190019.194263-2-kuba@kernel.org>
Here's the full review on the website if it helps:
https://sashiko.dev/#/patchset/20260319224159.23885-1-emil.s.tantilov%40intel.com
Thanks,
Jake
On 4/18/2026 12:00 PM, Jakub Kicinski wrote:
> This is an AI-generated review of your patch. The human sending this
> email has considered the AI review valid, or at least plausible.
>
> Jakub: I'll drop this patch and apply the rest.
> ---
> idpf: fix xdp crash in soft reset error path
>
> This commit fixes a NULL pointer dereference in idpf_vport_open() when
> soft reset fails by restoring vport->xdp_prog to the old value. It also
> updates the restart check to use IDPF_VPORT_UP instead of netif_running().
>
> Cc: stable@vger.kernel.org
>
>> diff --git a/drivers/net/ethernet/intel/idpf/xdp.c b/drivers/net/ethernet/intel/idpf/xdp.c
>> --- a/drivers/net/ethernet/intel/idpf/xdp.c
>> +++ b/drivers/net/ethernet/intel/idpf/xdp.c
>> @@ -488,6 +488,7 @@ static int idpf_xdp_setup_prog(struct idpf_vport *vport,
>> "Could not reopen the vport after XDP setup");
>>
>> cfg->user_config.xdp_prog = old;
>> + vport->xdp_prog = old;
>
> Does this also need to roll back vport->num_xdp_txq?
>
> Because idpf_initiate_soft_reset() overwrites the vport struct with the new
> queue configuration before failing, vport->num_xdp_txq might remain > 0
> while vport->xdp_prog is restored to NULL.
>
> When the interface is brought up, idpf_xdpsqs_get() evaluates
> idpf_xdp_enabled(vport) as false and returns early without allocating the
> NAPI timers (xdpsq->timer).
>
> Could another interface redirect XDP frames via ndo_xdp_xmit, bypassing the
> check because vport->num_xdp_txq > 0, and cause a NULL pointer dereference
> in libeth_xdpsq_queue_timer() during idpf_xdp_tx_finalize()?
>
>> old = prog;
>> }
>
> Is this old = prog assignment leading to a double-put of the BPF program?
>
> If idpf_initiate_soft_reset() fails, this error path drops a reference to
> the newly provided prog when it calls bpf_prog_put(old) right after this
> block.
>
> Since the function returns an error code to the core network stack, won't
> dev_xdp_install() in net/core/dev.c also explicitly call bpf_prog_put(prog)
> assuming ownership of the error cleanup?
>
> Could this underflow the reference count and cause a use-after-free?
>
> [ ... ]
>
>> diff --git a/drivers/net/ethernet/intel/idpf/xsk.c b/drivers/net/ethernet/intel/idpf/xsk.c
>> --- a/drivers/net/ethernet/intel/idpf/xsk.c
>> +++ b/drivers/net/ethernet/intel/idpf/xsk.c
>> @@ -568,7 +569,8 @@ int idpf_xsk_pool_setup(struct idpf_vport *vport, struct netdev_bpf *bpf)
>> return -EINVAL;
>> }
>>
>> - restart = idpf_xdp_enabled(vport) && netif_running(vport->netdev);
>> + restart = idpf_xdp_enabled(vport) &&
>> + test_bit(IDPF_VPORT_UP, np->state);
>> if (!restart)
>> goto pool;
>
> Does this function leave the queue pair permanently disabled if the pool
> setup fails?
>
> If restart is true, the queue pair is disabled via:
> idpf_qp_switch(vport, qid, false);
>
> If the subsequent call to libeth_xsk_setup_pool() fails, the function
> returns early:
>
> ret = libeth_xsk_setup_pool(vport->netdev, qid, pool);
> if (ret) {
> ...
> return ret;
> }
>
> Does this early return bypass the idpf_qp_switch(vport, qid, true) call
> expected later, causing a permanent partial loss of connectivity until the
> interface is manually restarted?
^ permalink raw reply
* Re: [PATCH net v2 8/8] xsk: fix u64 descriptor address truncation on 32-bit architectures
From: Stanislav Fomichev @ 2026-04-20 19:49 UTC (permalink / raw)
To: Jason Xing
Cc: davem, edumazet, kuba, pabeni, bjorn, magnus.karlsson,
maciej.fijalkowski, jonathan.lemon, sdf, ast, daniel, hawk,
john.fastabend, bpf, netdev, Jason Xing
In-Reply-To: <20260420082805.14844-9-kerneljasonxing@gmail.com>
On 04/20, Jason Xing wrote:
> From: Jason Xing <kernelxing@tencent.com>
>
> In copy mode TX, xsk_skb_destructor_set_addr() stores the 64-bit
> descriptor address into skb_shinfo(skb)->destructor_arg (void *) via a
> uintptr_t cast:
>
> skb_shinfo(skb)->destructor_arg = (void *)((uintptr_t)addr | 0x1UL);
>
> On 32-bit architectures uintptr_t is 32 bits, so the upper 32 bits of
> the descriptor address are silently dropped. In XDP_ZEROCOPY unaligned
> mode the chunk offset is encoded in bits 48-63 of the descriptor
> address (XSK_UNALIGNED_BUF_OFFSET_SHIFT = 48), meaning the offset is
> lost entirely. The completion queue then returns a truncated address to
> userspace, making buffer recycling impossible.
>
> Fix this by handling the 32-bit case directly in
> xsk_skb_destructor_set_addr(): when !CONFIG_64BIT, allocate an xsk_addrs
> struct (the same path already used for multi-descriptor SKBs) to store
> the full u64 address.
Is it easier to make XSK `depends on 64BIT` to avoid dealing with that? Does
anybody seriously run af_xdp on 32 bit systems?
^ permalink raw reply
* Re: [PATCH] gtp: disable BH before calling udp_tunnel_xmit_skb()
From: Jakub Kicinski @ 2026-04-20 19:58 UTC (permalink / raw)
To: Justin Iurman
Cc: David Carlier, Pablo Neira Ayuso, Harald Welte, Andrew Lunn,
Eric Dumazet, Paolo Abeni, Weiming Shi, osmocom-net-gprs, netdev,
linux-kernel, stable
In-Reply-To: <b44de581-9f41-4804-afb1-72c491d9443a@gmail.com>
On Mon, 20 Apr 2026 21:02:55 +0200 Justin Iurman wrote:
> On 4/17/26 07:54, David Carlier wrote:
> > gtp_genl_send_echo_req() runs as a generic netlink doit handler in
> > process context with BH not disabled. It calls udp_tunnel_xmit_skb(),
> > which eventually invokes iptunnel_xmit() — that uses __this_cpu_inc/dec
> > on softnet_data.xmit.recursion to track the tunnel xmit recursion level.
> >
> > Without local_bh_disable(), the task may migrate between
> > dev_xmit_recursion_inc() and dev_xmit_recursion_dec(), breaking the
> > per-CPU counter pairing. The result is stale or negative recursion
> > levels that can later produce false-positive
> > SKB_DROP_REASON_RECURSION_LIMIT drops on either CPU.
> >
> > The other udp_tunnel_xmit_skb() call sites in gtp.c are unaffected:
> > the data path runs under ndo_start_xmit and the echo response handlers
> > run from the UDP encap rx softirq, both with BH already disabled.
> >
> > Fix it by disabling BH around the udp_tunnel_xmit_skb() call, mirroring
> > commit 2cd7e6971fc2 ("sctp: disable BH before calling
> > udp_tunnel_xmit_skb()").
>
> Why not fix iptunnel_xmit() directly, rather than fixing all possible
> callers? Basically, jut like we did for lwtunnel_{output|xmit}(). The
> advantage would be that we no longer have to worry about BHs in the
> callers, and BHs would only be disabled when necessary.
Oops, I pushed this already. The bot hasn't caught up yet.
Let's revisit this if we find another caller in process context?
^ permalink raw reply
* Re: [PATCH net v2 7/8] xsk: fix xsk_addrs slab leak on multi-buffer error path
From: Stanislav Fomichev @ 2026-04-20 19:58 UTC (permalink / raw)
To: Jason Xing
Cc: davem, edumazet, kuba, pabeni, bjorn, magnus.karlsson,
maciej.fijalkowski, jonathan.lemon, sdf, ast, daniel, hawk,
john.fastabend, bpf, netdev, Jason Xing
In-Reply-To: <20260420082805.14844-8-kerneljasonxing@gmail.com>
On 04/20, Jason Xing wrote:
> From: Jason Xing <kernelxing@tencent.com>
>
> When xsk_build_skb() / xsk_build_skb_zerocopy() sees the first
> continuation descriptor, it promotes destructor_arg from an inlined
> address to a freshly allocated xsk_addrs (num_descs = 1). The counter
> is bumped to >= 2 only at the very end of a successful build (by calling
> xsk_inc_num_desc()).
>
> If the build fails in between (e.g. alloc_page() returns NULL with
> -EAGAIN, or the MAX_SKB_FRAGS overflow hits), we jump to free_err, skip
> calling xsk_inc_num_desc() to increment num_descs and leave the half-built
> skb attached to xs->skb for the app to retry. The skb now has
> 1) destructor_arg = a real xsk_addrs pointer,
> 2) num_descs = 1
>
> If the app never retries and just close()s the socket, xsk_release()
> calls xsk_drop_skb() -> xsk_consume_skb(), which decides whether to
> free xsk_addrs by testing num_descs > 1:
>
> if (unlikely(num_descs > 1))
> kmem_cache_free(xsk_tx_generic_cache, destructor_arg);
>
> Because num_descs is exactly 1 the branch is skipped and the
> xsk_addrs object is leaked to the xsk_tx_generic_cache slab.
>
> Fix it by directly testing if destructor_arg is still addr. Or else it
> is modified and used to store the newly allocated memory from
> xsk_tx_generic_cache regardless of increment of num_desc, which we
> need to handle.
>
> Closes: https://lore.kernel.org/all/20260419045824.D9E5EC2BCAF@smtp.kernel.org/
> Fixes: 0ebc27a4c67d ("xsk: avoid data corruption on cq descriptor number")
> Signed-off-by: Jason Xing <kernelxing@tencent.com>
> ---
> net/xdp/xsk.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/net/xdp/xsk.c b/net/xdp/xsk.c
> index 9236ec32b54a..6b17974ca825 100644
> --- a/net/xdp/xsk.c
> +++ b/net/xdp/xsk.c
> @@ -605,7 +605,7 @@ static void xsk_cq_submit_addr_locked(struct xsk_buff_pool *pool,
> spin_lock_irqsave(&pool->cq_prod_lock, flags);
> idx = xskq_get_prod(pool->cq);
>
> - if (unlikely(num_descs > 1)) {
> + if (unlikely(!xsk_skb_destructor_is_addr(skb))) {
> xsk_addr = (struct xsk_addrs *)skb_shinfo(skb)->destructor_arg;
>
> for (i = 0; i < num_descs; i++) {
> @@ -660,7 +660,7 @@ static void xsk_consume_skb(struct sk_buff *skb)
> u32 num_descs = xsk_get_num_desc(skb);
> struct xsk_addrs *xsk_addr;
>
> - if (unlikely(num_descs > 1)) {
> + if (unlikely(!xsk_skb_destructor_is_addr(skb))) {
> xsk_addr = (struct xsk_addrs *)skb_shinfo(skb)->destructor_arg;
> kmem_cache_free(xsk_tx_generic_cache, xsk_addr);
> }
> --
> 2.41.3
>
Acked-by: Stanislav Fomichev <sdf@fomichev.me>
^ permalink raw reply
* Re: [PATCH] connector/Kconfig: Enable CONFIG_CONNECTOR by default
From: Jakub Kicinski @ 2026-04-20 20:18 UTC (permalink / raw)
To: Qais Yousef
Cc: Andrew Lunn, David S . Miller, Eric Dumazet, Paolo Abeni, netdev,
linux-kernel, Vincent Guittot, John Stultz, Steven Rostedt
In-Reply-To: <20260419214217.108901-1-qyousef@layalina.io>
On Sun, 19 Apr 2026 22:42:17 +0100 Qais Yousef wrote:
> To make new tools that depend on it like schedqos [1] more reliable, it
> is important to ensure users can find it by default on all system.
If scheduler maintainers think this is appropriate they should take
this patch via their tree (please). connector falls under networking
for historical reasons (it's Netlink based) but we lack the context
necessary to apply a "default y" patch of this nature.
default y should be used if the symbol is necessary for most Linux
users across use cases and architectures. It's not obvious to me
that that is the case here. The commit message links to a tool
which is less than a week old?
^ permalink raw reply
* Re: [PATCH 2/2] bpf: guard sock_ops rtt_min against non-locked tcp_sock
From: Martin KaFai Lau @ 2026-04-20 20:43 UTC (permalink / raw)
To: Werner Kasselman
Cc: bpf@vger.kernel.org, netdev@vger.kernel.org, andrii@kernel.org,
ast@kernel.org, brakmo@fb.com, daniel@iogearbox.net,
davem@davemloft.net, eddyz87@gmail.com, edumazet@google.com,
haoluo@google.com, horms@kernel.org, john.fastabend@gmail.com,
jolsa@kernel.org, kpsingh@kernel.org, kuba@kernel.org,
linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org,
pabeni@redhat.com, sdf@fomichev.me, shuah@kernel.org,
song@kernel.org, yonghong.song@linux.dev, jiayuan.chen@linux.dev,
stable@vger.kernel.org
In-Reply-To: <20260417023119.3830723-3-werner@verivus.com>
On Fri, Apr 17, 2026 at 02:31:26AM +0000, Werner Kasselman wrote:
> diff --git a/net/core/filter.c b/net/core/filter.c
> index e8ad062f63bc..9c43193a5c39 100644
> --- a/net/core/filter.c
> +++ b/net/core/filter.c
> @@ -10827,14 +10827,12 @@ static u32 sock_ops_convert_ctx_access(enum bpf_access_type type,
> sizeof(struct minmax));
> BUILD_BUG_ON(sizeof(struct minmax) <
> sizeof(struct minmax_sample));
> + BUILD_BUG_ON(offsetof(struct tcp_sock, rtt_min) +
> + offsetof(struct minmax_sample, v) > S16_MAX);
This doesn't look like a test that is added by human.
Will sizeof(tcp_sock) ever reach S16_MAX? It is unnecessarily defensive and
inconsistent with other tcp_sock field loads.
> diff --git a/tools/testing/selftests/bpf/prog_tests/sock_ops_get_sk.c b/tools/testing/selftests/bpf/prog_tests/sock_ops_get_sk.c
> index 343d92c4df30..1aea4c97d5d3 100644
> --- a/tools/testing/selftests/bpf/prog_tests/sock_ops_get_sk.c
> +++ b/tools/testing/selftests/bpf/prog_tests/sock_ops_get_sk.c
Separate the test in its own patch.
Also tag and add revision to subject, "[PATCH v3 bpf...]".
Take a look at how other patches are posted in the bpf mailing list.
pw-bot: cr
^ permalink raw reply
* Re: [PATCH net v2] selftests: netfilter: conntrack_sctp_collision.sh: Introduce SCTP INIT collision test
From: Xin Long @ 2026-04-20 20:52 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Yi Chen, Pablo Neira Ayuso, Florian Westphal, Phil Sutter,
David S . Miller, Eric Dumazet, Paolo Abeni, Simon Horman,
Shuah Khan, coreteam, netfilter-devel, linux-kselftest,
linux-kernel, netdev
In-Reply-To: <20260420082334.7db8cbf4@kernel.org>
On Mon, Apr 20, 2026 at 11:23 AM Jakub Kicinski <kuba@kernel.org> wrote:
>
> On Sun, 19 Apr 2026 03:58:43 +0800 Yi Chen wrote:
> > The existing test covered a scenario where a delayed INIT_ACK chunk
> > updates the vtag in conntrack after the association has already been
> > established.
>
> AI says:
>
> The conntrack_sctp_collision.sh selftest is now failing in the NIPA CI on
> both the normal and debug kernel builds:
>
> not ok 1 1 selftests: net/netfilter: conntrack_sctp_collision.sh # exit=1
>
> # Test for SCTP INIT_ACK Collision in nf_conntrack:
> # Invalid netns name ""
> # Invalid netns name ""
>
> The root cause is a shell variable scoping bug introduced by this patch.
> The new test structure wraps `topo_setup` in a subshell:
>
> (topo_setup && conf_delay $SERVER_NS link0 2) || exit $?
Better to change it to:
topo_setup || exit $?
conf_delay $SERVER_NS link0 2 || exit $?
Again, please do not post the patch until the fix gets merged into net.git:
https://lore.kernel.org/netdev/cover.1775847557.git.lucien.xin@gmail.com/
Otherwise, it will still be failing in the NIPA CI.
Thanks.
> if ! do_test; then
> ...
> fi
>
> `topo_setup` calls `setup_ns CLIENT_NS SERVER_NS ROUTER_NS`, which sets
> those variables inside the subshell. Those assignments do not propagate
> back to the parent shell, so when `do_test` is called afterwards, both
> `$SERVER_NS` and `$CLIENT_NS` expand to empty strings. The `ip net exec ""`
> calls then fail with "Invalid netns name """.
>
> The second test case (SCTP INIT Collision) would have the same problem.
>
> The fix is to avoid the subshell or ensure the namespace variables are
> visible to `do_test`. The simplest approach is to remove the subshell
> wrapping and call `topo_setup`, `conf_delay`, and `do_test` in the same
> shell scope:
>
> topo_setup && conf_delay "$SERVER_NS" link0 2 || exit $?
> if ! do_test; then
> exit $ksft_fail
> fi
>
> topo_setup && conf_delay "$CLIENT_NS" link3 1 || exit $?
> if ! do_test; then
> exit $ksft_fail
> fi
>
> Please also note that `conf_delay` references `$ROUTER_NS` directly
> (not via a parameter), so it too requires that those variables be set
> in the same shell scope.
^ permalink raw reply
* [syzbot] [net?] [usb?] KASAN: slab-use-after-free Read in rtl8150_start_xmit
From: syzbot @ 2026-04-20 21:47 UTC (permalink / raw)
To: andrew+netdev, davem, edumazet, kuba, linux-kernel, linux-usb,
netdev, pabeni, petkan, syzkaller-bugs
Hello,
syzbot found the following issue on:
HEAD commit: c1f49dea2b8f Merge tag 'mm-hotfixes-stable-2026-04-19-00-1..
git tree: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git usb-testing
console output: https://syzkaller.appspot.com/x/log.txt?x=158822d2580000
kernel config: https://syzkaller.appspot.com/x/.config?x=547af2cd0df5277f
dashboard link: https://syzkaller.appspot.com/bug?extid=3f46c095ac0ca048cb71
compiler: gcc (Debian 14.2.0-19) 14.2.0, GNU ld (GNU Binutils for Debian) 2.44
Unfortunately, I don't have any reproducer for this issue yet.
Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/b0b2d34cef3a/disk-c1f49dea.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/54e06fcfd92f/vmlinux-c1f49dea.xz
kernel image: https://storage.googleapis.com/syzbot-assets/0aa8d05931c2/bzImage-c1f49dea.xz
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+3f46c095ac0ca048cb71@syzkaller.appspotmail.com
==================================================================
BUG: KASAN: slab-use-after-free in rtl8150_start_xmit+0x71f/0x760 drivers/net/usb/rtl8150.c:712
Read of size 4 at addr ffff88810eb7a930 by task kworker/0:4/5226
CPU: 0 UID: 0 PID: 5226 Comm: kworker/0:4 Not tainted syzkaller #0 PREEMPT(full)
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/18/2026
Workqueue: mld mld_ifc_work
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:94 [inline]
dump_stack_lvl+0x100/0x190 lib/dump_stack.c:120
print_address_description mm/kasan/report.c:378 [inline]
print_report+0x13d/0x4b0 mm/kasan/report.c:482
kasan_report+0xdf/0x1d0 mm/kasan/report.c:595
rtl8150_start_xmit+0x71f/0x760 drivers/net/usb/rtl8150.c:712
__netdev_start_xmit include/linux/netdevice.h:5343 [inline]
netdev_start_xmit include/linux/netdevice.h:5352 [inline]
xmit_one net/core/dev.c:3888 [inline]
dev_hard_start_xmit+0x128/0x7a0 net/core/dev.c:3904
sch_direct_xmit+0x194/0x890 net/sched/sch_generic.c:372
__dev_xmit_skb net/core/dev.c:4209 [inline]
__dev_queue_xmit+0x278a/0x4930 net/core/dev.c:4831
dev_queue_xmit include/linux/netdevice.h:3401 [inline]
neigh_resolve_output net/core/neighbour.c:1619 [inline]
neigh_resolve_output+0x51d/0x8f0 net/core/neighbour.c:1599
neigh_output include/net/neighbour.h:556 [inline]
ip6_finish_output2+0xa92/0x1f20 net/ipv6/ip6_output.c:136
__ip6_finish_output+0x359/0xd10 net/ipv6/ip6_output.c:208
ip6_finish_output net/ipv6/ip6_output.c:219 [inline]
NF_HOOK_COND include/linux/netfilter.h:307 [inline]
ip6_output+0x2a1/0xa50 net/ipv6/ip6_output.c:246
dst_output include/net/dst.h:470 [inline]
NF_HOOK.constprop.0+0x115/0x5a0 include/linux/netfilter.h:318
mld_sendpack+0x923/0xef0 net/ipv6/mcast.c:1855
mld_send_cr net/ipv6/mcast.c:2154 [inline]
mld_ifc_work+0x75a/0xc10 net/ipv6/mcast.c:2693
process_one_work+0xa0e/0x1980 kernel/workqueue.c:3302
process_scheduled_works kernel/workqueue.c:3385 [inline]
worker_thread+0x5ef/0xe50 kernel/workqueue.c:3466
kthread+0x370/0x450 kernel/kthread.c:436
ret_from_fork+0x69a/0xc80 arch/x86/kernel/process.c:158
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
</TASK>
Allocated by task 5226:
kasan_save_stack+0x30/0x50 mm/kasan/common.c:57
kasan_save_track+0x14/0x30 mm/kasan/common.c:78
unpoison_slab_object mm/kasan/common.c:340 [inline]
__kasan_slab_alloc+0x6e/0x70 mm/kasan/common.c:366
kasan_slab_alloc include/linux/kasan.h:253 [inline]
slab_post_alloc_hook mm/slub.c:4569 [inline]
slab_alloc_node mm/slub.c:4898 [inline]
kmem_cache_alloc_node_noprof+0x26b/0x6b0 mm/slub.c:4950
__alloc_skb+0x140/0x710 net/core/skbuff.c:702
alloc_skb include/linux/skbuff.h:1383 [inline]
mld_newpack.isra.0+0x18e/0xa30 net/ipv6/mcast.c:1775
add_grhead+0x299/0x340 net/ipv6/mcast.c:1886
add_grec+0x139a/0x1940 net/ipv6/mcast.c:2025
mld_send_cr net/ipv6/mcast.c:2148 [inline]
mld_ifc_work+0x3c5/0xc10 net/ipv6/mcast.c:2693
process_one_work+0xa0e/0x1980 kernel/workqueue.c:3302
process_scheduled_works kernel/workqueue.c:3385 [inline]
worker_thread+0x5ef/0xe50 kernel/workqueue.c:3466
kthread+0x370/0x450 kernel/kthread.c:436
ret_from_fork+0x69a/0xc80 arch/x86/kernel/process.c:158
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
Freed by task 2860:
kasan_save_stack+0x30/0x50 mm/kasan/common.c:57
kasan_save_track+0x14/0x30 mm/kasan/common.c:78
kasan_save_free_info+0x3b/0x70 mm/kasan/generic.c:584
poison_slab_object mm/kasan/common.c:253 [inline]
__kasan_mempool_poison_object+0x91/0x150 mm/kasan/common.c:539
kasan_mempool_poison_object include/linux/kasan.h:363 [inline]
napi_skb_cache_put+0x68/0x740 net/core/skbuff.c:1459
net_tx_action+0x2b0/0xf90 net/core/dev.c:5807
handle_softirqs+0x1dd/0x9e0 kernel/softirq.c:622
__do_softirq kernel/softirq.c:656 [inline]
invoke_softirq kernel/softirq.c:496 [inline]
__irq_exit_rcu+0x160/0x210 kernel/softirq.c:735
irq_exit_rcu+0x9/0x30 kernel/softirq.c:752
instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1061 [inline]
sysvec_apic_timer_interrupt+0x8f/0xb0 arch/x86/kernel/apic/apic.c:1061
asm_sysvec_apic_timer_interrupt+0x1a/0x20 arch/x86/include/asm/idtentry.h:697
The buggy address belongs to the object at ffff88810eb7a8c0
which belongs to the cache skbuff_head_cache of size 232
The buggy address is located 112 bytes inside of
freed 232-byte region [ffff88810eb7a8c0, ffff88810eb7a9a8)
The buggy address belongs to the physical page:
page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x10eb7a
flags: 0x200000000000000(node=0|zone=2)
page_type: f5(slab)
raw: 0200000000000000 ffff888102e8c8c0 dead000000000100 dead000000000122
raw: 0000000000000000 00000008000c000c 00000000f5000000 0000000000000000
page dumped because: kasan: bad access detected
page_owner tracks the page as allocated
page last allocated via order 0, migratetype Unmovable, gfp_mask 0xd2820(GFP_ATOMIC|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP|__GFP_NOMEMALLOC), pid 2971, tgid 2971 (syz-executor), ts 110258130289, free_ts 109191008280
set_page_owner include/linux/page_owner.h:32 [inline]
post_alloc_hook+0x153/0x170 mm/page_alloc.c:1858
prep_new_page mm/page_alloc.c:1866 [inline]
get_page_from_freelist+0xf34/0x3a90 mm/page_alloc.c:3946
__alloc_frozen_pages_noprof+0x273/0x28a0 mm/page_alloc.c:5226
alloc_slab_page mm/slub.c:3278 [inline]
allocate_slab mm/slub.c:3467 [inline]
new_slab+0xa6/0x6b0 mm/slub.c:3525
refill_objects+0x277/0x420 mm/slub.c:7251
refill_sheaf mm/slub.c:2816 [inline]
__pcs_replace_empty_main+0x375/0x650 mm/slub.c:4651
alloc_from_pcs mm/slub.c:4749 [inline]
slab_alloc_node mm/slub.c:4883 [inline]
kmem_cache_alloc_noprof+0x520/0x6a0 mm/slub.c:4905
skb_clone+0x190/0x400 net/core/skbuff.c:2107
dev_queue_xmit_nit+0x255/0xa80 net/core/dev.c:2574
xmit_one net/core/dev.c:3884 [inline]
dev_hard_start_xmit+0x2fc/0x7a0 net/core/dev.c:3904
sch_direct_xmit+0x194/0x890 net/sched/sch_generic.c:372
__dev_xmit_skb net/core/dev.c:4209 [inline]
__dev_queue_xmit+0x278a/0x4930 net/core/dev.c:4831
dev_queue_xmit include/linux/netdevice.h:3401 [inline]
neigh_hh_output include/net/neighbour.h:540 [inline]
neigh_output include/net/neighbour.h:554 [inline]
ip_finish_output2+0xea0/0x2350 net/ipv4/ip_output.c:237
__ip_finish_output.part.0+0x1b4/0x350 net/ipv4/ip_output.c:315
__ip_finish_output net/ipv4/ip_output.c:303 [inline]
ip_finish_output net/ipv4/ip_output.c:325 [inline]
NF_HOOK_COND include/linux/netfilter.h:307 [inline]
ip_output+0x392/0xc00 net/ipv4/ip_output.c:438
dst_output include/net/dst.h:470 [inline]
ip_local_out+0x193/0x1f0 net/ipv4/ip_output.c:131
page last free pid 5250 tgid 5248 stack trace:
reset_page_owner include/linux/page_owner.h:25 [inline]
__free_pages_prepare mm/page_alloc.c:1402 [inline]
__free_frozen_pages+0x692/0xf10 mm/page_alloc.c:2943
tlb_batch_list_free mm/mmu_gather.c:161 [inline]
tlb_finish_mmu+0x27d/0x810 mm/mmu_gather.c:552
exit_mmap+0x454/0xa10 mm/mmap.c:1313
__mmput kernel/fork.c:1178 [inline]
mmput+0xe0/0x430 kernel/fork.c:1201
exit_mm kernel/exit.c:581 [inline]
do_exit+0x833/0x2a60 kernel/exit.c:963
do_group_exit+0xd5/0x2a0 kernel/exit.c:1117
get_signal+0x1ec7/0x21e0 kernel/signal.c:3037
arch_do_signal_or_restart+0x91/0x7a0 arch/x86/kernel/signal.c:337
__exit_to_user_mode_loop kernel/entry/common.c:64 [inline]
exit_to_user_mode_loop+0x7e/0x430 kernel/entry/common.c:98
__exit_to_user_mode_prepare include/linux/irq-entry-common.h:207 [inline]
syscall_exit_to_user_mode_prepare include/linux/irq-entry-common.h:238 [inline]
syscall_exit_to_user_mode include/linux/entry-common.h:328 [inline]
do_syscall_64+0x682/0x7f0 arch/x86/entry/syscall_64.c:100
entry_SYSCALL_64_after_hwframe+0x77/0x7f
Memory state around the buggy address:
ffff88810eb7a800: fb fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc
ffff88810eb7a880: fc fc fc fc fc fc fc fc fa fb fb fb fb fb fb fb
>ffff88810eb7a900: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
^
ffff88810eb7a980: fb fb fb fb fb fc fc fc fc fc fc fc fc fc fc fc
ffff88810eb7aa00: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
==================================================================
---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
If the report is already addressed, let syzbot know by replying with:
#syz fix: exact-commit-title
If you want to overwrite report's subsystems, reply with:
#syz set subsystems: new-subsystem
(See the list of subsystem names on the web dashboard)
If the report is a duplicate of another one, reply with:
#syz dup: exact-subject-of-another-report
If you want to undo deduplication, reply with:
#syz undup
^ permalink raw reply
* Re: [PATCH net v6 1/2] flow_dissector: do not dissect PPPoE PFC frames
From: patchwork-bot+netdevbpf @ 2026-04-20 21:59 UTC (permalink / raw)
To: Qingfang Deng
Cc: linux-ppp, davem, edumazet, kuba, pabeni, horms, gnault,
wojciech.drewek, anthony.l.nguyen, netdev, linux-kernel, paulus,
jaco, carlsonj, marcin.szycik
In-Reply-To: <20260415022456.141758-1-qingfang.deng@linux.dev>
Hello:
This series was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Wed, 15 Apr 2026 10:24:50 +0800 you wrote:
> RFC 2516 Section 7 states that Protocol Field Compression (PFC) is NOT
> RECOMMENDED for PPPoE. In practice, pppd does not support negotiating
> PFC for PPPoE sessions, and the flow dissector driver has assumed an
> uncompressed frame until the blamed commit.
>
> During the review process of that commit [1], support for PFC is
> suggested. However, having a compressed (1-byte) protocol field means
> the subsequent PPP payload is shifted by one byte, causing 4-byte
> misalignment for the network header and an unaligned access exception
> on some architectures.
>
> [...]
Here is the summary with links:
- [net,v6,1/2] flow_dissector: do not dissect PPPoE PFC frames
https://git.kernel.org/netdev/net/c/d6c19b31a3c1
- [net,v6,2/2] pppoe: drop PFC frames
https://git.kernel.org/netdev/net/c/cc1ff87bce1c
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
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