Re: [PATCH net-next 5/5] net: drop GSO skbs instead of handing them to XDP

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] net: late GSO check in generic XDP causes DoS via skb_linearize()
- [Medium] veth: explicitly dropped GSO packets bypass kfree_skb tracepoints
--

commit 9f35b405d194efb7bc146b2c667a7b894d4c2f17
Author: Jakub Kicinski <kuba@kernel.org>
Subject: net: drop GSO skbs instead of handing them to XDP

This commit explicitly drops GSO packets on input to XDP since XDP lacks
helpers to fix up GSO state after modifications. It adds a check to generic
XDP and veth paths to intercept and drop these packets.

> diff --git a/drivers/net/veth.c b/drivers/net/veth.c
> index 71227d0389aa5..5635037e3b605 100644
> --- a/drivers/net/veth.c
> +++ b/drivers/net/veth.c
> @@ -756,6 +756,9 @@ static int veth_convert_skb_to_xdp_buff(struct veth_rq *rq,
>  	struct sk_buff *skb = *pskb;
>  	u32 frame_sz;
>  
> +	if (unlikely(xdp_skb_feature_check(skb)))
> +		goto drop;
> +

[Severity: Medium]
When jumping to the drop label here, the code uses consume_skb():

veth_convert_skb_to_xdp_buff() {
	...
drop:
	consume_skb(skb);
	*pskb = NULL;

	return -ENOMEM;
}

Because *pskb is set to NULL, the caller's kfree_skb() on the error path
does nothing. Does this bypass network drop observability tools like
dropwatch, since consume_skb() makes it look like the packet was
successfully consumed instead of explicitly dropped?

>  	if (skb_shared(skb) || skb_head_is_locked(skb) ||
>  	    skb_is_nonlinear(skb) ||
>  	    skb_headroom(skb) < XDP_PACKET_HEADROOM) {

[ ... ]

> diff --git a/net/core/dev.c b/net/core/dev.c
> index 096d1dedebfd4..fbeb3df4c11f7 100644
> --- a/net/core/dev.c
> +++ b/net/core/dev.c
[ ... ]
> @@ -5516,6 +5517,9 @@ u32 bpf_prog_run_generic_xdp(struct sk_buff *skb, struct xdp_buff *xdp,
>  	u32 metalen, act;
>  	int off;
>  
> +	if (unlikely(xdp_skb_feature_check(skb)))
> +		return XDP_DROP;
> +

[Severity: High]
Does this check happen too late for generic XDP?

In netif_receive_generic_xdp(), nonlinear and GSO packets are handled by
calling netif_skb_check_for_xdp() which triggers skb_linearize() before
this new check is reached:

netif_receive_generic_xdp() {
	...
	if (skb_cloned(skb) || skb_is_nonlinear(skb) ||
	    skb_headroom(skb) < XDP_PACKET_HEADROOM) {
		if (netif_skb_check_for_xdp(pskb, xdp_prog))
			goto do_drop;
	}
	...
	act = bpf_prog_run_generic_xdp(*pskb, xdp, xdp_prog);
	...
}

Because xdp_skb_feature_check() is added inside bpf_prog_run_generic_xdp(),
could this force the host to perform an expensive memory allocation and copy
to linearize large GSO packets, only to immediately drop them afterwards? 

Could this be exploited as a Denial of Service vector by flooding large GSO
packets?

>  	/* The XDP program wants to see the packet starting at the MAC
>  	 * header.
>  	 */

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260928223648.2739371-1-kuba@kernel.org?part=5