Re: [PATCH net-next 4/4] net: Fix UDP length overflow with PMTU discover and big MTU

[Willem de Bruijn <willemdebruijn.kernel@gmail.com>]

Alice Mikityanska wrote:
> On Thu, Aug 6, 2026, at 06:26, Willem de Bruijn wrote:
> > Alice Mikityanska wrote:
> >> From: Alice Mikityanska <alice@isovalent.com>
> >> 
> >> This commit bounds cork->base.fragsize to IP(6)_MAX_MTU to avoid a
> >> possible overflow of UDP length that triggers a WARN in
> >> udp_set_len_short when setsockopt IP(V6)_MTU_DISCOVER is set to
> >> IPV6_PMTUDISC_DO or IP(V6)_PMTUDISC_PROBE, and a large packet is sent
> >> over a netdev with an unusually large MTU.
> >> 
> >> Steps to reproduce (included in the new selftest):
> >> 
> >> 1. Set device MTU bigger than IP6_MAX_MTU (or IP_MAX_MTU + 20).
> >>    cork->base.fragsize will be set to that MTU in ip(6)_setup_cork.
> >> 2. Set IP(V6)_MTU_DISCOVER to IP(V6)_PMTUDISC_PROBE or IPV6_PMTUDISC_DO.
> >>    It lets maxnonfragsize be set to device MTU (cork->fragsize) in
> >>    __ip(6)_append_data, rather than to IP(6)_MAX_MTU.

In __ip6_append_data I only see

        if (ip6_sk_ignore_df(sk))
                maxnonfragsize = sizeof(struct ipv6hdr) + IPV6_MAXPLEN;
        else
                maxnonfragsize = mtu;

> >> 3. Send 65528 bytes of payload (+8 bytes of UDP header, +20/40 bytes of
> >>    IPv4/IPv6 header). Device MTU allows it (it's only one byte bigger
> >>    than IP6_MAX_MTU or IP_MAX_MTU + IPv4 header, and the device MTU is
> >>    bigger than that).
> >> 4. The UDP length in the built packet is 65536, which overflows the
> >>    16-bit length field and triggers the WARN in udp_set_len_short.
> >
> > This is discovered thanks to udp_set_len_short, but is this a
> > preexisting bug and the fix go to net with a Fixes tag?
> 
> You're right, it's preexisting, it can go to net.
> 
> For the Fixes tag, I'm not sure about the first occurrence of this bug.
> It could even be as old as 1470ddf7f8ce ("inet: Remove explicit write
> references to sk/inet in ip_append_data"), but I can't compile this
> kernel with modern tools and check myself, unless I bring up some VM
> with an ancient distro from 2011. And I guess, it could be even older,
> as corking existed before. At the same time, something else might have
> prevented this bug back then.
> 
> If needed, I can try to do this archaeology.

I also suspect that this has been present for a long time, given that
your repro does not exercise anything particularly new.

Definitely no need to try to reproduce on an ancient system. We can
estimate the introduction based on code analysis.

In practice, most important is that the Fixes correcty identifies all
relevant active stable branches that could use the fix. If helpful, I
can also take a look.

Aside: I was not even aware that devices allow setting a device MTU
beyond ETH_MAX_MTU. But loopback indeed has no dev->max_mtu and
accepts up to INT32_MAX.
 
> >> Note: IP_PMTUDISC_DO with IPv4 is safe, because ip_dst_mtu_maybe_forward
> >> always clamps at IP_MAX_MTU, unlike ip6_dst_mtu_maybe_forward.
> >
> > That was introduced in commit 14972cbd34ff ("net: lwtunnel: Handle
> > fragmentation"), the message of which includes "This includes .. some
> > mtu fixes" without elaborating on those.
> >
> > That introduced the same clamp in ip6_mtu. Which was removed in
> > commit 427faee167bc ("net: ipv6: introduce ip6_dst_mtu_maybe_forward")
> 
> Looks like it could be by accident, it's a refactoring commit. The
> similar change for IPv4 in commit ac6627a28dbf ("net: ipv4: Consolidate
> ipv4_mtu and ip_dst_mtu_maybe_forward") preserves the clamp.
> 
> > Tangential to this fix, but maybe that should be reinstated. I don't
> > immediately see why the two would diverge on this point.
> 
> I agree; even though the output case should be fixed by my patch, it
> might still be relevant for forwarding. Let's see if Vadim has any
> comment on the history of the above.
> 
> >> Reported-by: syzbot+ce13c07d96d04716eaa2@syzkaller.appspotmail.com
> >> Closes: https://lore.kernel.org/netdev/6a6a966c.86abc875.e5c3d.0054.GAE@google.com/
> >> Signed-off-by: Alice Mikityanska <alice@isovalent.com>
> >> Assisted-by: Claude:claude-sonnet-4.6
> >> Cc: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
> >
> > I only see this patch 4/4. Is there more that did not make it to the list?
> 
> Sorry, I sent it like this by accident, this is an only patch in this
> submission.

That explains. No worries.