Re: [PATCH net-next v9 4/9] udp: Support gro_ipv4_max_size > 65536

[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 [4]: [PATCH net-next v9 4/9] udp: Support gro_ipv4_max_size > 65536 ---
commit 6dfda0f76318408b2e2b33603d561940b926529c
Author: Alice Mikityanska <alice@isovalent.com>
Subject: udp: Support gro_ipv4_max_size > 65536

This commit fixes UDP GRO aggregation for packets larger than 65536 bytes
by setting the UDP length field to 0 during GRO and restoring the true length
from skb->len in udp_rcv().

> diff --git a/net/ipv4/udp_offload.c b/net/ipv4/udp_offload.c
> index 493e2b9e16fbc..4f9a3922937cc 100644
> --- a/net/ipv4/udp_offload.c
> +++ b/net/ipv4/udp_offload.c
> @@ -919,7 +919,7 @@ int udp_gro_complete(struct sk_buff *skb, int nhoff,
>  	struct sock *sk;
>  	int err;
>  
> -	udp_set_len_short(uh, newlen);
> +	udp_set_len(uh, newlen);

[Severity: High]
Does setting the UDP length to 0 here (for packets > 65535 bytes) break
software segmentation?

In net/ipv4/udp_offload.c:__udp_gso_segment(), the code adjusts the
pseudo-header checksum by subtracting uh->len:

    check = csum16_add(csum16_sub(uh->check, uh->len), htons(newlen));

If uh->len is 0 for BIG TCP packets, this subtraction will fail to remove
the true 32-bit original length from the checksum.

Similarly, in net/ipv4/udp_offload.c:__skb_udp_tunnel_segment(), partial
GSO relies on uh->len to negate the old length:

    if (skb_shinfo(skb)->gso_type & SKB_GSO_PARTIAL)
        partial = (__force __wsum)uh->len;
    else
        partial = (__force __wsum)htonl(skb->len);
    partial = csum_sub(csum_unfold(uh->check), partial);

Will forwarding BIG TCP over UDP packets that fall back to software
segmentation result in corrupted checksums for all generated segments?