Re: [PATCH net-next v9 5/9] udp: Validate UDP length in udp_gro_receive

[Simon Horman <horms@kernel.org>]

This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.
Full review at: https://sashiko.dev
---
--- Patch [5]: [PATCH net-next v9 5/9] udp: Validate UDP length in udp_gro_receive ---
commit f1316d873c7549e0a49dc98d7614be1dc5b0f66c
Author: Alice Mikityanska <alice@isovalent.com>

udp: Validate UDP length in udp_gro_receive

This patch adds an early check for malformed or padded UDP packets with
len=0 at udp_gro_receive to exclude them from GRO, moving the check out of
udp_gro_receive_segment.

> diff --git a/net/ipv4/udp_offload.c b/net/ipv4/udp_offload.c
> index 4f9a3922937cc..8f77c8788f6db 100644
> --- a/net/ipv4/udp_offload.c
> +++ b/net/ipv4/udp_offload.c

[ ... ]

> @@ -782,8 +778,14 @@ struct sk_buff *udp_gro_receive(struct list_head *head, struct sk_buff *skb,
>  	struct sk_buff *p;
>  	struct udphdr *uh2;
>  	unsigned int off = skb_gro_offset(skb);
> +	unsigned int ulen;
>  	int flush = 1;
>  
> +	/* Do not deal with padded or malicious packets, sorry! */
> +	ulen = udp_get_len_short(uh);
> +	if (ulen <= sizeof(*uh) || ulen != skb_gro_len(skb))
> +		goto out;
> +

[Severity: High]
Could this early return bypass inner GRO flow matching for padded UDP tunnel
packets?

When a padded UDP tunnel packet, such as a small TCP ACK inside VXLAN or
GENEVE, arrives in net/ipv4/udp_offload.c:udp_gro_receive() while previous
packets of the same inner flow are held in the GRO list, the
ulen != skb_gro_len(skb) check evaluates to true and triggers the goto out.

Because the goto out path yields pp = NULL and flush = 1, dev_gro_receive()
passes the new padded packet to the network stack immediately, leaving older
packets stuck in the GRO list.

Before this change, the packet would reach inner GRO handlers (like
tcp4_gro_receive()) which would detect the sequence or padding mismatch,
set flush = 1, and return the held packet via pp = p. This ensured older
packets were flushed to the stack before the new padded packet, preserving
delivery order.

Will bypassing this inner flow matching lead to out-of-order delivery for
the inner protocol, resulting in duplicate ACKs and throughput degradation?

>  	/* We can do L4 aggregation only if the packet can't land in a tunnel
>  	 * otherwise we could corrupt the inner stream. Detecting such packets
>  	 * cannot be foolproof and the aggregation might still happen in some