From: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
To: <netdev-bot+sashiko@kernel.org>
Cc: <netdev@vger.kernel.org>, <magnus.karlsson@intel.com>,
<stfomichev@gmail.com>, <kuba@kernel.org>, <pabeni@redhat.com>,
<tushar.vyavahare@intel.com>, <kerneljasonxing@gmail.com>,
<bjorn@kernel.org>, <zuomao338@gmail.com>
Subject: Re: [PATCH net 1/9] xsk: fix list corruption in xsk_buff_add_frag()
Date: Tue, 3 Nov 2026 17:24:28 +0100 [thread overview]
Message-ID: <auoKvG01wDpW8uQJ@boxer> (raw)
In-Reply-To: <179371274919.488856.4452814542770594161@kernel.org>
On Tue, Nov 03, 2026 at 01:32:29PM +0000, netdev-bot+sashiko@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 3 potential
> issue(s) to consider.
>
> Critical: 0 · High: 2 · Medium: 0 · Low: 1 (1)
>
> If you believe none of the issues are legitimate, please reply to each
> issue of Medium severity or higher and explain why the AI is wrong.
> If any of them are legitimate and you plan to respin, please let patchwork
> know by including "pw-bot: cr" as a separate line at the end of your reply
> (one such reply per series is enough).
>
> - [High] At the reviewed commit, the new `xdp == head` rejection in
> xsk_buff_add_frag() (include/net/xdp_sock_drv.h:166-168) runs after…
> - [High] At the reviewed commit, the new rejection in xsk_buff_add_frag()
> fails the same way every time it sees the same input.
> - [Low] The kernel-doc for libeth_xsk_buff_add_frag()
> (drivers/net/ethernet/intel/libeth/xsk.c:50-51) says it returns '%NULL…
>
> Pre-existing issues:
> - [Low] When xsk_buff_add_frag() fails, ice_clean_rx_irq_zc() frees the
> partial frame and sets first = NULL but does not skip ahead to EOP.
>
Note: I will be trimming away all the issues where beloved bot says 'a
later patch in the series seems to fix this'. This is really annoying :<
> --
>
> xsk: fix list corruption in xsk_buff_add_frag()
>
> This patch changes xsk_buff_add_frag() to reject a frag buffer that is the
> frame head or that is already linked on pool->xskb_list or
> pool->free_list. In aligned mode this happens when user space posts the
> same fill ring address twice. The goal is to prevent list corruption and
> the resulting NULL pointer dereference in xp_free().
>
> > diff --git a/include/net/xdp_sock_drv.h b/include/net/xdp_sock_drv.h
> > index d94aeb506379c..29965e3695983 100644
> > --- a/include/net/xdp_sock_drv.h
> > +++ b/include/net/xdp_sock_drv.h
> > @@ -160,15 +160,18 @@ static inline void xsk_buff_free(struct xdp_buff *xdp)
> > static inline bool xsk_buff_add_frag(struct xdp_buff *head,
> > struct xdp_buff *xdp)
> > {
> > + struct xdp_buff_xsk *frag = container_of(xdp, struct xdp_buff_xsk, xdp);
> > const void *data = xdp->data;
> > - struct xdp_buff_xsk *frag;
> > +
> > + /* Duplicate fill ring entries map to the same xskb in aligned mode */
> > + if (unlikely(xdp == head || !list_empty(&frag->list_node)))
> > + return false;
>
> [Severity: Low]
> This is a pre-existing issue and was not introduced by this patch, but
> this check makes the caller failure paths reachable through duplicate fill
> ring entries.
>
> In ice_clean_rx_irq_zc(), a failed xsk_buff_add_frag() frees the partial
> frame and sets first to NULL, but the remaining descriptors up to EOP are
> not skipped:
>
> } else if (likely(size) && !xsk_buff_add_frag(first, xdp)) {
> xsk_buff_free(first);
> first = NULL;
> }
>
> Won't the rest of the hardware frame then be assembled and delivered as a
> new frame? idpf_xskrq_poll() does the same when libeth_xsk_process_buff()
> returns NULL.
>
> The i40e patch later in this series calls this intended ("The rest of the
> dropped frame is received as a new frame"). It also does not appear to
> corrupt kernel memory, so it may be acceptable as is.
Hm, yeah seems like frame should be drained up to EOP...it's best to do on
driver side.
Clashiko 1:2 Maciej
as two issues were just bonkers, they are fixed later.
>
> [Severity: Low]
> This isn't a bug, but the kernel-doc for libeth_xsk_buff_add_frag() in
> drivers/net/ethernet/intel/libeth/xsk.c still lists running out of frag
> space as the only failure reason:
>
> * Return: main buffer with attached frag on success, %NULL on error (no space
> * for a new frag).
>
> With these new checks, it also returns NULL when the frag is the head, or
> when it is already on pool->xskb_list or pool->free_list. Should that
> comment be updated too? The text is unchanged at the end of the series.
>
> >
> > if (!__xdp_buff_add_frag(head, virt_to_netmem(data),
> > offset_in_page(data), xdp->data_end - data,
> > xdp->frame_sz, false))
> > return false;
>
> [ ... ]
>
> --
> Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20261102124950.958345-1-maciej.fijalkowski%40intel.com
next prev parent reply other threads:[~2026-11-03 16:24 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-02 12:49 [PATCH net 0/9] xsk: ZC mbuf fixes Maciej Fijalkowski
2026-11-02 12:49 ` [PATCH net 1/9] xsk: fix list corruption in xsk_buff_add_frag() Maciej Fijalkowski
2026-11-03 13:32 ` netdev-bot+sashiko
2026-11-03 16:24 ` Maciej Fijalkowski [this message]
2026-11-02 12:49 ` [PATCH net 2/9] i40e: xsk: fix xsk_buff_add_frag() error handling in Rx Maciej Fijalkowski
2026-11-03 13:32 ` netdev-bot+sashiko
2026-11-03 16:29 ` Maciej Fijalkowski
2026-11-02 12:49 ` [PATCH net 3/9] ice: xsk: fix leaking Rx buffers in multi-buffer path Maciej Fijalkowski
2026-11-03 13:32 ` netdev-bot+sashiko
2026-11-03 17:22 ` Maciej Fijalkowski
2026-11-02 12:49 ` [PATCH net 4/9] ice: xsk: do not free in-flight frags on XDP_TX completion Maciej Fijalkowski
2026-11-02 12:49 ` [PATCH net 5/9] libeth: " Maciej Fijalkowski
2026-11-03 13:32 ` netdev-bot+sashiko
2026-11-02 12:49 ` [PATCH net 6/9] xsk: do not clear frags flag when acquiring a buffer Maciej Fijalkowski
2026-11-03 13:32 ` netdev-bot+sashiko
2026-11-02 12:49 ` [PATCH net 7/9] i40e: xsk: fix multi-buffer XDP_PASS skb construction Maciej Fijalkowski
2026-11-02 12:49 ` [PATCH net 8/9] ice: xsk: free stashed Rx frame when cleaning the ring Maciej Fijalkowski
2026-11-02 12:49 ` [PATCH net 9/9] idpf: free stashed XSk Rx frame when releasing the queue Maciej Fijalkowski
2026-11-03 13:32 ` netdev-bot+sashiko
2026-11-02 12:54 ` [PATCH net 0/9] xsk: ZC mbuf fixes netdev-bot+sinfo
2026-11-02 13:18 ` Maciej Fijalkowski
2026-11-03 4:48 ` Björn Töpel
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=auoKvG01wDpW8uQJ@boxer \
--to=maciej.fijalkowski@intel.com \
--cc=bjorn@kernel.org \
--cc=kerneljasonxing@gmail.com \
--cc=kuba@kernel.org \
--cc=magnus.karlsson@intel.com \
--cc=netdev-bot+sashiko@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=stfomichev@gmail.com \
--cc=tushar.vyavahare@intel.com \
--cc=zuomao338@gmail.com \
/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.