Re: [PATCH net v3] veth: convert frag_list skbs before running XDP

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [Critical] `skb_pp_cow_data` fails to account for `skb_shared_info` overhead in `truesize`, leading to memory corruption and `skb_over_panic`.
--

--- Patch [1]: [PATCH net v3] veth: convert frag_list skbs before running XDP ---
commit 2a77993dec578b7da44e393d4e9fecc7e0e8c05c
Author: Matt Fleming <mfleming@cloudflare.com>

veth: convert frag_list skbs before running XDP

This commit fixes an AF_XDP copy mode crash by routing nonlinear skbs through
skb_pp_cow_data() before exposing them to XDP, preventing empty frags[] from
being exposed.

> diff --git a/drivers/net/veth.c b/drivers/net/veth.c
> index 1c51421491753..00e34afd858e7 100644
> --- a/drivers/net/veth.c
> +++ b/drivers/net/veth.c
> @@ -756,7 +756,7 @@ static int veth_convert_skb_to_xdp_buff(struct veth_rq *rq,
>  	u32 frame_sz;
>  
>  	if (skb_shared(skb) || skb_head_is_locked(skb) ||
> -	    skb_shinfo(skb)->nr_frags ||
> +	    skb_is_nonlinear(skb) ||
>  	    skb_headroom(skb) < XDP_PACKET_HEADROOM) {
>  		if (skb_pp_cow_data(rq->page_pool, pskb, XDP_PACKET_HEADROOM))
>  			goto drop;

[Severity: Critical]
This isn't a bug introduced by this patch, but does changing this condition
route more traffic into a memory corruption issue inside skb_pp_cow_data()?

Looking at skb_pp_cow_data() in net/core/skbuff.c, it computes the allocation
size without accounting for the skb_shared_info structural overhead:

        truesize = SKB_HEAD_ALIGN(size) + headroom;
        data = page_pool_dev_alloc_va(pool, &truesize);

When page_pool_dev_alloc_va() allocates from a page fragment (which happens
when the requested size is <= PAGE_SIZE / 2), it returns a buffer of exactly
the requested size. 

The subsequent call to napi_build_skb() unconditionally subtracts the
skb_shared_info overhead from this size, setting skb->end below the required
bounds. This causes the payload copy in skb_copy_bits() to overwrite the
shared info, and later skb_put() calls will crash with an skb_over_panic.

Since standard 1500-byte MTU packets satisfy this fragment threshold
(1792 <= 2048), will routing all nonlinear SKBs into this path allow remote
input to reliably trigger a kernel panic?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260722191925.2192070-1-matt@readmodwrite.com?part=1