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

On Thu, Aug 6, 2026, at 18:06, Willem de Bruijn wrote:
> Alice Mikityanska wrote:
>> On Thu, Aug 6, 2026, at 06:26, Willem de Bruijn wrote:
>> > Alice Mikityanska wrote:
>> >> From: Alice Mikityanska <[email protected]>
>> >> 
>> >> 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;

That's right; ip6_sk_ignore_df is false in DO and PROBE modes, and mtu
comes from cork->fragsize above:

mtu = cork->gso_size ? IP6_MAX_MTU : cork->fragsize;

>> >> 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.

I found the first commit where it reproduces, will resubmit to
net shortly.

> 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.

Yeah, at least dummy and loopback allow that. I agree it's unlikely to
happen in real-world environments, but syzbot still found it.

>> >> 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: [email protected]
>> >> Closes: https://lore.kernel.org/netdev/[email protected]/
>> >> Signed-off-by: Alice Mikityanska <[email protected]>
>> >> Assisted-by: Claude:claude-sonnet-4.6
>> >> Cc: Willem de Bruijn <[email protected]>
>> >
>> > 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.