All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Jason Xing" <kerneljasonxing@gmail.com>
Cc: bpf@vger.kernel.org
Subject: Re: [PATCH net v2 8/8] xsk: fix u64 descriptor address truncation on 32-bit architectures
Date: Tue, 21 Apr 2026 09:40:25 +0000	[thread overview]
Message-ID: <20260421094026.6543DC2BCB0@smtp.kernel.org> (raw)
In-Reply-To: <20260420082805.14844-9-kerneljasonxing@gmail.com>

Sashiko AI review found 1 potential issue(s):
- [High] On 32-bit systems, xsk_drop_untrans_skb() will call kmem_cache_free() on an uninitialized destructor_arg pointer in early allocation failure paths, causing slab corruption.
--

commit cf643670755512ad76d19d6d0707e86a2a05c671
Author: Jason Xing <kerneljasonxing@gmail.com>

xsk: fix u64 descriptor address truncation on 32-bit architectures

This commit fixes a truncation issue of the 64-bit descriptor address
on 32-bit architectures by allocating an xsk_addrs struct to store the
full address instead of packing it into the destructor_arg pointer.
It also updates the related cleanup and initialization functions to
handle the newly allocated struct.

Link: https://lore.kernel.org/all/20260419045824.D9E5EC2BCAF@smtp.kernel.org/

> diff --git a/net/xdp/xsk.c b/net/xdp/xsk.c
> index 9c06a4e868725..0232559d5348f 100644
> --- a/net/xdp/xsk.c
> +++ b/net/xdp/xsk.c
[ ... ]
> @@ -799,6 +825,12 @@ static int xsk_skb_metadata(struct sk_buff *skb, void *buffer,
>  
>  static void xsk_drop_untrans_skb(struct sk_buff *skb)
>  {
> +	if (!IS_ENABLED(CONFIG_64BIT) && !xsk_skb_destructor_is_addr(skb)) {
> +		struct xsk_addrs *xsk_addr;
> +
> +		xsk_addr = (struct xsk_addrs *)skb_shinfo(skb)->destructor_arg;
> +		kmem_cache_free(xsk_tx_generic_cache, xsk_addr);
> +	}

Could this pass an uninitialized pointer to kmem_cache_free() and cause slab
corruption?

When a new socket buffer is allocated via sock_alloc_send_skb(), the
networking core's __alloc_skb() function only zeroes the skb_shared_info
struct up to the dataref field. The destructor_arg field resides after
dataref and contains uninitialized garbage from the slab.

If an error occurs before destructor_arg is explicitly initialized, such as
when xsk_skb_init_misc() returns -ENOMEM:

xsk_build_skb_zerocopy()
    ...
    skb = sock_alloc_send_skb(&xs->sk, hr, 1, &err);
    ...
    err = xsk_skb_init_misc(skb, xs, desc->addr);
    if (unlikely(err)) {
        xsk_drop_untrans_skb(skb);
        return ERR_PTR(err);
    }

In xsk_drop_untrans_skb() on 32-bit systems, xsk_skb_destructor_is_addr(skb)
evaluates to !skb_shinfo(skb)->destructor_arg. Because destructor_arg
contains non-zero garbage, the function returns false. The check in
xsk_drop_untrans_skb() (!xsk_skb_destructor_is_addr(skb)) then succeeds,
passing the garbage pointer to kmem_cache_free().

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

  parent reply	other threads:[~2026-04-21  9:40 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
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 [this message]
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=20260421094026.6543DC2BCB0@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=kerneljasonxing@gmail.com \
    --cc=sashiko@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 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.