From: Jesper Dangaard Brouer <hawk@kernel.org>
To: Maciej Fijalkowski <maciej.fijalkowski@intel.com>,
bpf@vger.kernel.org, ast@kernel.org, daniel@iogearbox.net,
ilias.apalodimas@linaro.org, toke@redhat.com, lorenzo@kernel.org,
kuba@kernel.org
Cc: netdev@vger.kernel.org, magnus.karlsson@intel.com,
andrii@kernel.org, stfomichev@gmail.com,
aleksander.lobakin@intel.com,
syzbot+ff145014d6b0ce64a173@syzkaller.appspotmail.com,
Ihor Solodrai <ihor.solodrai@linux.dev>,
Octavian Purdila <tavip@google.com>
Subject: Re: [PATCH v2 bpf 1/2] xdp: update xdp_rxq_info's mem type in XDP generic hook
Date: Mon, 20 Oct 2025 13:20:57 +0200 [thread overview]
Message-ID: <50cbda75-9e0c-4d04-8d01-75dc533b8bb9@kernel.org> (raw)
In-Reply-To: <20251017143103.2620164-2-maciej.fijalkowski@intel.com>
On 17/10/2025 16.31, Maciej Fijalkowski wrote:
> Currently, generic XDP hook uses xdp_rxq_info from netstack Rx queues
> which do not have its XDP memory model registered. There is a case when
> XDP program calls bpf_xdp_adjust_tail() BPF helper, which in turn
> releases underlying memory. This happens when it consumes enough amount
> of bytes and when XDP buffer has fragments. For this action the memory
> model knowledge passed to XDP program is crucial so that core can call
> suitable function for freeing/recycling the page.
>
> For netstack queues it defaults to MEM_TYPE_PAGE_SHARED (0) due to lack
> of mem model registration. The problem we're fixing here is when kernel
> copied the skb to new buffer backed by system's page_pool and XDP buffer
> is built around it. Then when bpf_xdp_adjust_tail() calls
> __xdp_return(), it acts incorrectly due to mem type not being set to
> MEM_TYPE_PAGE_POOL and causes a page leak.
>
Does the code not set the skb->pp_recycle ?
> Pull out the existing code from bpf_prog_run_generic_xdp() that
> init/prepares xdp_buff onto new helper xdp_convert_skb_to_buff() and
> embed there rxq's mem_type initialization that is assigned to xdp_buff.
>
> This problem was triggered by syzbot as well as AF_XDP test suite which
> is about to be integrated to BPF CI.
>
> Reported-by: syzbot+ff145014d6b0ce64a173@syzkaller.appspotmail.com
> Closes: https://lore.kernel.org/netdev/6756c37b.050a0220.a30f1.019a.GAE@google.com/
> Fixes: e6d5dbdd20aa ("xdp: add multi-buff support for xdp running in generic mode")
> Tested-by: Ihor Solodrai <ihor.solodrai@linux.dev>
> Co-developed-by: Octavian Purdila <tavip@google.com>
> Signed-off-by: Octavian Purdila <tavip@google.com> # whole analysis, testing, initiating a fix
> Signed-off-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com> # commit msg and proposed more robust fix
> ---
> include/net/xdp.h | 31 +++++++++++++++++++++++++++++++
> net/core/dev.c | 25 ++++---------------------
> 2 files changed, 35 insertions(+), 21 deletions(-)
>
> diff --git a/include/net/xdp.h b/include/net/xdp.h
> index aa742f413c35..51f3321e4f94 100644
> --- a/include/net/xdp.h
> +++ b/include/net/xdp.h
> @@ -384,6 +384,37 @@ struct sk_buff *xdp_build_skb_from_frame(struct xdp_frame *xdpf,
> struct net_device *dev);
> struct xdp_frame *xdpf_clone(struct xdp_frame *xdpf);
>
> +static inline
> +void xdp_convert_skb_to_buff(struct sk_buff *skb, struct xdp_buff *xdp,
> + struct xdp_rxq_info *xdp_rxq)
> +{
I really like that this is getting put into a helper function :-)
> + u32 frame_sz, mac_len;
> + void *hard_start;
> +
> + /* The XDP program wants to see the packet starting at the MAC
> + * header.
> + */
> + mac_len = skb->data - skb_mac_header(skb);
> + hard_start = skb->data - skb_headroom(skb);
> +
> + /* SKB "head" area always have tailroom for skb_shared_info */
> + frame_sz = skb_end_pointer(skb) - skb->head;
> + frame_sz += SKB_DATA_ALIGN(sizeof(struct skb_shared_info));
> + xdp_init_buff(xdp, frame_sz, xdp_rxq);
> + xdp_prepare_buff(xdp, hard_start, skb_headroom(skb) - mac_len,
> + skb_headlen(skb) + mac_len, true);
> +
> + if (skb_is_nonlinear(skb)) {
> + skb_shinfo(skb)->xdp_frags_size = skb->data_len;
> + xdp_buff_set_frags_flag(xdp);
> + } else {
> + xdp_buff_clear_frags_flag(xdp);
> + }
> +
The SKB should be marked via skb->pp_recycle, but I guess you are trying
to catch code that doesn't set this correctly?
(Slightly worried this will "paper-over" some other buggy code?)
> + xdp->rxq->mem.type = page_pool_page_is_pp(virt_to_page(xdp->data)) ?
> + MEM_TYPE_PAGE_POOL : MEM_TYPE_PAGE_SHARED;
> +}
In the beginning PP_MAGIC / PP_SIGNATURE was primarily used as a
debugging feature to catch faulty code that released pp pages to the
real page allocator. It seems to have evolved into something more
critical. Someone also tried to elevate this into a page flag, which
would make this more reliable.
> +
> static inline
> void xdp_convert_frame_to_buff(const struct xdp_frame *frame,
> struct xdp_buff *xdp)
> diff --git a/net/core/dev.c b/net/core/dev.c
> index a64cef2c537e..3d607dce292b 100644
> --- a/net/core/dev.c
> +++ b/net/core/dev.c
> @@ -5320,35 +5320,18 @@ static struct netdev_rx_queue *netif_get_rxqueue(struct sk_buff *skb)
> u32 bpf_prog_run_generic_xdp(struct sk_buff *skb, struct xdp_buff *xdp,
> const struct bpf_prog *xdp_prog)
> {
> - void *orig_data, *orig_data_end, *hard_start;
> + void *orig_data, *orig_data_end;
> struct netdev_rx_queue *rxqueue;
> bool orig_bcast, orig_host;
> - u32 mac_len, frame_sz;
> + u32 metalen, act, mac_len;
> __be16 orig_eth_type;
> struct ethhdr *eth;
> - u32 metalen, act;
> int off;
>
> - /* The XDP program wants to see the packet starting at the MAC
> - * header.
> - */
> + rxqueue = netif_get_rxqueue(skb);
> mac_len = skb->data - skb_mac_header(skb);
> - hard_start = skb->data - skb_headroom(skb);
> -
> - /* SKB "head" area always have tailroom for skb_shared_info */
> - frame_sz = (void *)skb_end_pointer(skb) - hard_start;
> - frame_sz += SKB_DATA_ALIGN(sizeof(struct skb_shared_info));
>
> - rxqueue = netif_get_rxqueue(skb);
> - xdp_init_buff(xdp, frame_sz, &rxqueue->xdp_rxq);
> - xdp_prepare_buff(xdp, hard_start, skb_headroom(skb) - mac_len,
> - skb_headlen(skb) + mac_len, true);
> - if (skb_is_nonlinear(skb)) {
> - skb_shinfo(skb)->xdp_frags_size = skb->data_len;
> - xdp_buff_set_frags_flag(xdp);
> - } else {
> - xdp_buff_clear_frags_flag(xdp);
> - }
> + xdp_convert_skb_to_buff(skb, xdp, &rxqueue->xdp_rxq);
>
> orig_data_end = xdp->data_end;
> orig_data = xdp->data;
next prev parent reply other threads:[~2025-10-20 11:21 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-17 14:31 [PATCH v2 bpf 0/2] xdp: fix page_pool leaks Maciej Fijalkowski
2025-10-17 14:31 ` [PATCH v2 bpf 1/2] xdp: update xdp_rxq_info's mem type in XDP generic hook Maciej Fijalkowski
2025-10-17 16:45 ` Toke Høiland-Jørgensen
2025-10-20 11:20 ` Jesper Dangaard Brouer [this message]
2025-10-20 15:36 ` Alexander Lobakin
2025-10-20 17:53 ` Maciej Fijalkowski
2025-10-22 1:01 ` Jakub Kicinski
2025-10-22 11:22 ` Maciej Fijalkowski
2025-10-22 14:04 ` Jakub Kicinski
2025-10-17 14:31 ` [PATCH v2 bpf 2/2] veth: update mem type in xdp_buff Maciej Fijalkowski
2025-10-17 16:33 ` Toke Høiland-Jørgensen
2025-10-17 16:52 ` Maciej Fijalkowski
2025-10-17 17:51 ` Toke Høiland-Jørgensen
2025-10-17 18:12 ` Toke Høiland-Jørgensen
2025-10-17 20:08 ` Maciej Fijalkowski
2025-10-20 10:25 ` Toke Høiland-Jørgensen
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=50cbda75-9e0c-4d04-8d01-75dc533b8bb9@kernel.org \
--to=hawk@kernel.org \
--cc=aleksander.lobakin@intel.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=ihor.solodrai@linux.dev \
--cc=ilias.apalodimas@linaro.org \
--cc=kuba@kernel.org \
--cc=lorenzo@kernel.org \
--cc=maciej.fijalkowski@intel.com \
--cc=magnus.karlsson@intel.com \
--cc=netdev@vger.kernel.org \
--cc=stfomichev@gmail.com \
--cc=syzbot+ff145014d6b0ce64a173@syzkaller.appspotmail.com \
--cc=tavip@google.com \
--cc=toke@redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).