BPF List
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Cen Zhang (Microsoft)" <blbllhy@gmail.com>
Cc: bpf@vger.kernel.org
Subject: Re: [PATCH net] xsk: fix NULL pointer dereference in __xsk_rcv()
Date: Sat, 25 Jul 2026 16:47:28 +0000	[thread overview]
Message-ID: <20260725164729.6BB941F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260724164719.99563-1-blbllhy@gmail.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Rolling back the RX ring via xskq_prod_cancel_n() leaks previously allocated UMEM buffers on multi-buffer packet allocation failure.
--

--- Patch [1]: [PATCH net] xsk: fix NULL pointer dereference in __xsk_rcv() ---
commit 53feb1519cd9a4933abf6d79d7b04cb89df34c4b
Author: Cen Zhang (Microsoft) <blbllhy@gmail.com>

xsk: fix NULL pointer dereference in __xsk_rcv()

This commit fixes a NULL pointer dereference in the multi-buffer receive path
of __xsk_rcv(). It introduces a check for when xsk_buff_alloc() fails and
uses xskq_prod_cancel_n() to roll back partially submitted RX ring descriptors
to ensure no incomplete multi-buffer packet is delivered to userspace.

> diff --git a/net/xdp/xsk.c b/net/xdp/xsk.c
> index b970f30ea9b9d..3aad3996bd803 100644
> --- a/net/xdp/xsk.c
> +++ b/net/xdp/xsk.c

[ ... ]

> @@ -348,6 +349,11 @@ static int __xsk_rcv(struct xdp_sock *xs, struct xdp_buff *xdp, u32 len)
>  		u32 copied;
>  
>  		xsk_xdp = xsk_buff_alloc(xs->pool);
> +		if (!xsk_xdp) {
> +			xskq_prod_cancel_n(xs->rx, nb_submitted);
> +			xs->rx_dropped++;
> +			return -ENOMEM;
> +		}

[Severity: High]
Does this error path leak the UMEM chunks from previous loop iterations?

If an earlier fragment was allocated and submitted to the RX ring via
__xsk_rcv_zc_safe() (which internally calls xp_release()), and a subsequent
allocation fails here, xskq_prod_cancel_n() rewinds the RX ring's local
producer pointer.

Because the previously reserved descriptors are cancelled without manually
retrieving and returning their UMEM chunks to the kernel's free list, will
those chunks be permanently lost, allowing a user to exhaust the shared
UMEM pools by intentionally feeding invalid descriptors?

>  		copy_to = xsk_xdp->data - meta_len;
>  
>  		copied = xsk_copy_xdp(copy_to, &copy_from, to_len, &from_len, &frag, rem);

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260724164719.99563-1-blbllhy@gmail.com?part=1

      parent reply	other threads:[~2026-07-25 16:47 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-24 16:47 [PATCH net] xsk: fix NULL pointer dereference in __xsk_rcv() Cen Zhang (Microsoft)
2026-07-24 22:45 ` Stanislav Fomichev
2026-07-25  3:00   ` Cen Zhang (Microsoft)
2026-07-25 16:47 ` sashiko-bot [this message]

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=20260725164729.6BB941F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=blbllhy@gmail.com \
    --cc=bpf@vger.kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox