Re: [PATCH bpf v3 1/2] bpf, veth: xdp: fix page_pool page leak on skb-backed XDP

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] veth_xdp_rcv_one() overwrites shared per-queue rq->xdp_rxq.mem.type state, corrupting subsequent SKB processing in the same NAPI poll and causing kernel panics.
--

commit 6d121019cfea2f329267400ac7c2525a49f34f53
Author: Jiayuan Chen <jiayuan.chen@linux.dev>

    bpf, veth: xdp: fix page_pool page leak on skb-backed XDP
    
    bpf_xdp_shrink_data() frees a released frag via __xdp_return() using
    xdp->rxq->mem.type, but that type is wrong for skb-backed XDP: the skb is
    cow'd into page_pool memory while the rxq still says MEM_TYPE_PAGE_SHARED.
    This fixes the resulting page pool panics by recording the memory type in
    the xdp_buff flags instead.

> diff --git a/drivers/net/veth.c b/drivers/net/veth.c
> index 6ed3ee81153fb..a3fdf1959b76c 100644
> --- a/drivers/net/veth.c
> +++ b/drivers/net/veth.c
> @@ -775,6 +775,12 @@ static int veth_convert_skb_to_xdp_buff(struct veth_rq *rq,
>  	if (skb_shinfo(skb)->nr_frags) {
>  		skb_shinfo(skb)->xdp_frags_size = skb->data_len;
>  		xdp_buff_set_frags_flag(xdp);
> +		/*
> +		 * A nonlinear skb was cow'd into rq->page_pool above, so the
> +		 * frags must be freed to that pool, not via the rxq's
> +		 * MEM_TYPE_PAGE_SHARED.
> +		 */
> +		xdp_buff_set_frag_pp(xdp);
>  	} else {
>  		xdp_buff_clear_frags_flag(xdp);
>  	}

[Severity: High]
This isn't a bug introduced by this patch, but can the shared per-queue memory
type state be clobbered during a mixed batch?

In veth_xdp_rcv_one(), the shared rq->xdp_rxq.mem.type state is overwritten
with the incoming frame's type without being restored:

veth_xdp_rcv_one() {
    ...
    case XDP_REDIRECT:
        orig_frame = *frame;
        xdp->rxq->mem.type = frame->mem_type;
    ...
}

If a single NAPI poll (veth_xdp_rcv) processes a batch containing a native
xdp_frame (e.g. MEM_TYPE_XSK_BUFF_POOL) followed by a standard sk_buff, the
next packet will be processed with the clobbered rxq->mem.type.

When veth_xdp_rcv_skb() processes the subsequent sk_buff, the BPF program
is executed with this clobbered state:

veth_xdp_rcv_skb() {
    ...
    act = bpf_prog_run_xdp(xdp_prog, xdp);
    ...
}

If this clobbered memory type is read by helpers like bpf_xdp_shrink_data(),
could it lead to a kernel panic? For instance, if clobbered to XSK_BUFF_POOL,
it would erroneously call xsk_buff_free() on a standard xdp_buff, resulting
in a garbage dereference.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260911135711.109338-1-jiayuan.chen@linux.dev?part=1