Re: [PATCH net-next v9 4/9] udp: Support gro_ipv4_max_size > 65536
From: Simon Horman <horms@kernel.org>
Date: 2026-07-16 14:48:03
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 [off-list ref] 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().
quoted hunk ↗ jump to hunk
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?