Re: [PATCH net-next v9 1/9] net: Use helpers to get/set UDP len tree-wide

On Thu, 16 Jul 2026 at 17:47, Simon Horman [off-list ref] wrote:

First, I'd like to emphasize that I'm merely converting direct uh.len
access to the new helper. If there is an existing bug with underflow,
my new helper will expose it with a WARN, which is good. But should
such bugs exist before this refactoring, I don't think that fixing all
of them is in scope of this series.

Addressing the AI concern directly, my AI claims that such underflow
is not possible:

For fragmented IEEE 802.15.4 packets:
- d_size is decoded from the FRAG1 header in net/ieee802154/6lowpan/reassembly.c:259.
- A FRAG1 packet with d_size < sizeof(struct ipv6hdr) is rejected at net/ieee802154/6lowpan/reassembly.c:270.
- UDP/IPHC decompression is invoked only after that validation, at net/ieee802154/6lowpan/reassembly.c:296.
- FRAGN packets do not invoke header decompression here; they are queued for reassembly.
For an unfragmented packet, d_size is explicitly set to zero at net/ieee802154/6lowpan/rx.c:103, selecting the else branch and avoiding the subtraction entirely.

The resulting massive unsigned value passed to udp_set_len_short() would
then trigger the DEBUG_NET_WARN_ON_ONCE, potentially causing a panic if
panic_on_warn is set.

quoted

[ ... ]

diff --git a/net/ipv4/udp_offload.c b/net/ipv4/udp_offload.c
index 29651b1a0bc70..493e2b9e16fbc 100644
--- a/net/ipv4/udp_offload.c
+++ b/net/ipv4/udp_offload.c

[ ... ]

@@ -915,12 +914,12 @@ static int udp_gro_complete_segment(struct sk_buff *skb)
 int udp_gro_complete(struct sk_buff *skb, int nhoff,
                   udp_lookup_t lookup)
 {
-     __be16 newlen = htons(skb->len - nhoff);
      struct udphdr *uh = (struct udphdr *)(skb->data + nhoff);
+     unsigned int newlen = skb->len - nhoff;
      struct sock *sk;
      int err;

-     uh->len = newlen;
+     udp_set_len_short(uh, newlen);

[Severity: High]
If gro_max_size is configured larger than 65535 (which is supported and used
for BIG TCP), can't UDP GRO aggregate packets such that newlen > 65535?

This is the first patch that just converted direct access to helpers.
Patch 4 "udp: Support gro_ipv4_max_size > 65536" explicitly enables
len > 64k and replaces this line with udp_set_len. This comment on
patch 1 is irrelevant because it assumes that functionality added in a
later patch should work in a prior patch.

This would instantly trigger the DEBUG_NET_WARN_ON_ONCE inside
udp_set_len_short() for legitimate large packets.

quoted

[ ... ]

diff --git a/net/ipv4/udp_tunnel_core.c b/net/ipv4/udp_tunnel_core.c
index 9ab3728f9630b..0fccb38f074d2 100644
--- a/net/ipv4/udp_tunnel_core.c
+++ b/net/ipv4/udp_tunnel_core.c

@@ -178,7 +178,7 @@ void udp_tunnel_xmit_skb(struct rtable *rt, struct sock *sk, struct sk_buff *skb

      uh->dest = dst_port;
      uh->source = src_port;
-     uh->len = htons(skb->len);
+     udp_set_len_short(uh, skb->len);

[Severity: High]
When transmitting a TCP BIG TCP packet (which can be > 64K) over a UDP
tunnel like VXLAN, skb->len will exceed 65535.

Does using udp_set_len_short() here incorrectly trigger the warning for
valid large GSO payloads?

Same here. This is replaced by udp_set_len, which supports len > 64k,
in the patch that actually enables len > 64k.

quoted

[ ... ]

diff --git a/net/ipv6/ip6_udp_tunnel.c b/net/ipv6/ip6_udp_tunnel.c
index 9adb5775487fa..dcff7fb16ff64 100644
--- a/net/ipv6/ip6_udp_tunnel.c
+++ b/net/ipv6/ip6_udp_tunnel.c

@@ -93,7 +93,7 @@ void udp_tunnel6_xmit_skb(struct dst_entry *dst, struct sock *sk,
      uh->dest = dst_port;
      uh->source = src_port;

-     uh->len = htons(skb->len);
+     udp_set_len_short(uh, skb->len);

[Severity: High]
This appears to have the same issue as IPv4 tunnels. If a large GSO payload
is sent through an IPv6 UDP tunnel, won't skb->len exceed 65535 and trigger
the warning?

Same here.

I'm sorry, but I highly doubt that these AI review comments were validated.