* [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
* Re: [PATCH net] net: mctp: fix don't require received header reserved bits to be zero
From: patchwork-bot+netdevbpf @ 2026-04-20 21:59 UTC (permalink / raw)
To: wit_yuan
Cc: jk, yuanzm2, matt, davem, edumazet, kuba, pabeni, netdev,
linux-kernel, stable
In-Reply-To: <20260417141340.5306-1-yuanzhaoming901030@126.com>
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Fri, 17 Apr 2026 22:13:40 +0800 you wrote:
> From: Yuan Zhaoming <yuanzm2@lenovo.com>
>
> From the MCTP Base specification (DSP0236 v1.2.1), the first byte of
> the MCTP header contains a 4 bit reserved field, and 4 bit version.
>
> On our current receive path, we require those 4 reserved bits to be
> zero, but the 9500-8i card is non-conformant, and may set these
> reserved bits.
>
> [...]
Here is the summary with links:
- [net] net: mctp: fix don't require received header reserved bits to be zero
https://git.kernel.org/netdev/net/c/a663bac71a2f
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 v5] openvswitch: cap upcall PID array size and pre-size vport replies
From: patchwork-bot+netdevbpf @ 2026-04-20 21:59 UTC (permalink / raw)
To: Weiming Shi
Cc: aconole, echaudro, i.maximets, davem, edumazet, kuba, pabeni,
horms, pshelar, tgraf, alexw, netdev, dev, xmei5
In-Reply-To: <20260416024653.153456-2-bestswngs@gmail.com>
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Wed, 15 Apr 2026 19:46:54 -0700 you wrote:
> The vport netlink reply helpers allocate a fixed-size skb with
> nlmsg_new(NLMSG_DEFAULT_SIZE, ...) but serialize the full upcall PID
> array via ovs_vport_get_upcall_portids(). Since
> ovs_vport_set_upcall_portids() accepts any non-zero multiple of
> sizeof(u32) with no upper bound, a CAP_NET_ADMIN user can install a PID
> array large enough to overflow the reply buffer, causing nla_put() to
> fail with -EMSGSIZE and hitting BUG_ON(err < 0). On systems with
> unprivileged user namespaces enabled (e.g., Ubuntu default), this is
> reachable via unshare -Urn since OVS vport mutation operations use
> GENL_UNS_ADMIN_PERM.
>
> [...]
Here is the summary with links:
- [net,v5] openvswitch: cap upcall PID array size and pre-size vport replies
https://git.kernel.org/netdev/net/c/2091c6aa0df6
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: airoha: Fix possible TX queue stall in airoha_qdma_tx_napi_poll()
From: patchwork-bot+netdevbpf @ 2026-04-20 21:59 UTC (permalink / raw)
To: Lorenzo Bianconi
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, horms,
linux-arm-kernel, linux-mediatek, netdev
In-Reply-To: <20260416-airoha-txq-potential-stall-v2-1-42c732074540@kernel.org>
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Thu, 16 Apr 2026 12:30:12 +0200 you wrote:
> Since multiple net_device TX queues can share the same hw QDMA TX queue,
> there is no guarantee we have inflight packets queued in hw belonging to a
> net_device TX queue stopped in the xmit path because hw QDMA TX queue
> can be full. In this corner case the net_device TX queue will never be
> re-activated. In order to avoid any potential net_device TX queue stall,
> we need to wake all the net_device TX queues feeding the same hw QDMA TX
> queue in airoha_qdma_tx_napi_poll routine.
>
> [...]
Here is the summary with links:
- [net,v2] net: airoha: Fix possible TX queue stall in airoha_qdma_tx_napi_poll()
https://git.kernel.org/netdev/net/c/b94769eb2f30
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] hv_sock: Report EOF instead of -EIO for FIN
From: patchwork-bot+netdevbpf @ 2026-04-20 21:59 UTC (permalink / raw)
To: Dexuan Cui
Cc: kys, haiyangz, wei.liu, longli, sgarzare, davem, edumazet, kuba,
pabeni, horms, niuxuewei.nxw, linux-hyperv, virtualization,
netdev, linux-kernel, stable, Ben.Hillis, levymitchell0
In-Reply-To: <20260416191433.840637-1-decui@microsoft.com>
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Thu, 16 Apr 2026 12:14:33 -0700 you wrote:
> Commit f0c5827d07cb unluckily causes a regression for the FIN packet,
> and the final read syscall gets an error rather than 0.
>
> Ideally, we would want to fix hvs_channel_readable_payload() so that it
> could return 0 in the FIN scenario, but it's not good for the hv_sock
> driver to use the VMBus ringbuffer's cached priv_read_index, which is
> internal data in the VMBus driver.
>
> [...]
Here is the summary with links:
- [net,v2] hv_sock: Report EOF instead of -EIO for FIN
https://git.kernel.org/netdev/net/c/f63152958994
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] gtp: disable BH before calling udp_tunnel_xmit_skb()
From: patchwork-bot+netdevbpf @ 2026-04-20 21:59 UTC (permalink / raw)
To: David CARLIER
Cc: pablo, laforge, andrew+netdev, edumazet, kuba, pabeni, bestswngs,
osmocom-net-gprs, netdev, linux-kernel, stable
In-Reply-To: <20260417055408.4667-1-devnexen@gmail.com>
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Fri, 17 Apr 2026 06:54:08 +0100 you 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.
>
> [...]
Here is the summary with links:
- gtp: disable BH before calling udp_tunnel_xmit_skb()
https://git.kernel.org/netdev/net/c/5638504a2aa9
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