All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stanislav Fomichev <sdf.kernel@gmail.com>
To: Jason Xing <kerneljasonxing@gmail.com>
Cc: bpf@vger.kernel.org, netdev@vger.kernel.org,
	Jason Xing <kernelxing@tencent.com>
Subject: Re: [PATCH net v2 4/8] xsk: prevent CQ desync when freeing half-built skbs in xsk_build_skb()
Date: Mon, 20 Apr 2026 12:34:34 -0700	[thread overview]
Message-ID: <7f15844902d6dcee6ba070b0f3002b20.sdf.kernel@gmail.com> (raw)
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?

  reply	other threads:[~2026-04-20 19:34 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-20  8:27 [PATCH net v2 0/8] xsk: fix bugs around xsk skb allocation Jason Xing
2026-04-20  8:27 ` [PATCH net v2 1/8] xsk: reject sw-csum UMEM binding to IFF_TX_SKB_NO_LINEAR devices Jason Xing
2026-04-20 19:34   ` Stanislav Fomichev
2026-04-20 23:51     ` Jason Xing
2026-04-21 22:20       ` Stanislav Fomichev
2026-04-21  9:40   ` sashiko-bot
2026-04-21 12:39     ` Jason Xing
2026-04-20  8:27 ` [PATCH net v2 2/8] xsk: handle NULL dereference of the skb without frags issue Jason Xing
2026-04-20 19:34   ` Stanislav Fomichev
2026-04-21  9:40   ` sashiko-bot
2026-04-21 12:46     ` Jason Xing
2026-04-20  8:28 ` [PATCH net v2 3/8] xsk: fix use-after-free of xs->skb in xsk_build_skb() free_err path Jason Xing
2026-04-20 19:34   ` Stanislav Fomichev
2026-04-21  0:01     ` Jason Xing
2026-04-21  9:40   ` sashiko-bot
2026-04-21 12:51     ` Jason Xing
2026-04-20  8:28 ` [PATCH net v2 4/8] xsk: prevent CQ desync when freeing half-built skbs in xsk_build_skb() Jason Xing
2026-04-20 19:34   ` Stanislav Fomichev [this message]
2026-04-21  0:51     ` Jason Xing
2026-04-20  8:28 ` [PATCH net v2 5/8] xsk: avoid skb leak in XDP_TX_METADATA case Jason Xing
2026-04-21  9:40   ` sashiko-bot
2026-04-21 12:58     ` Jason Xing
2026-04-20  8:28 ` [PATCH net v2 6/8] xsk: free the skb when hitting the upper bound MAX_SKB_FRAGS Jason Xing
2026-04-20  8:28 ` [PATCH net v2 7/8] xsk: fix xsk_addrs slab leak on multi-buffer error path Jason Xing
2026-04-20 19:58   ` Stanislav Fomichev
2026-04-20  8:28 ` [PATCH net v2 8/8] xsk: fix u64 descriptor address truncation on 32-bit architectures Jason Xing
2026-04-20 19:49   ` Stanislav Fomichev
2026-04-21  0:49     ` Jason Xing
2026-04-21 22:23       ` Stanislav Fomichev
2026-04-22  2:54         ` Jason Xing
2026-04-21  9:40   ` sashiko-bot
2026-04-21 13:01     ` Jason Xing

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7f15844902d6dcee6ba070b0f3002b20.sdf.kernel@gmail.com \
    --to=sdf.kernel@gmail.com \
    --cc=bpf@vger.kernel.org \
    --cc=kerneljasonxing@gmail.com \
    --cc=kernelxing@tencent.com \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.