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

[Jiayuan Chen <jiayuan.chen@linux.dev>]

On 9/11/26 10:36 PM, sashiko-bot@kernel.org wrote:
> 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


The premise doesn't hold here: frame->mem_type is never 
MEM_TYPE_XSK_BUFF_POOL.


A zc buff gets copied out before it can ever become a frame. 
xdp_convert_buff_to_frame() sends

every XSK buff to xdp_convert_zc_to_xdp_frame(), and that one does:

     xdpf->mem_type = MEM_TYPE_PAGE_ORDER0;

     xsk_buff_free(xdp);


so the plain "xdp_frame->mem_type = xdp->rxq->mem.type" further down 
only ever sees non-XSK types.

I grepped the tree and the only things that ever  end up in a frame's 
mem_type are PAGE_SHARED,

PAGE_POOL and PAGE_ORDER0. So "xdp->rxq->mem.type = frame->mem_type" in 
veth_xdp_rcv_one() can't put

XSK in there, and the XSK branch in bpf_xdp_shrink_data() is simply not 
reachable from veth.


> 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.
>