Re: [PATCH net v3 2/4] net: ipv6: Fix UDP length overflow with PMTU discover and big MTU

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

Alice Mikityanska wrote:
> From: Alice Mikityanska <alice@isovalent.com>
> 
> This commit bounds cork->base.fragsize to IP6_MAX_MTU to avoid a

in v3 it only does so for UDP due to IPv6 jumbograms.

> possible overflow of UDP length that triggers a WARN in
> udp_set_len_short when setsockopt IPV6_MTU_DISCOVER is set to
> IPV6_PMTUDISC_DO or IPV6_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. cork->base.fragsize will be
>    set to that MTU in ip6_setup_cork.
> 2. Set IPV6_MTU_DISCOVER to IPV6_PMTUDISC_PROBE or IPV6_PMTUDISC_DO. It
>    lets maxnonfragsize be set to device MTU (cork->fragsize) in
>    __ip6_append_data, rather than to IP6_MAX_MTU.
> 3. Send 65528 bytes of payload (+8 bytes of UDP header, +40 bytes of
>    IPv6 header). Device MTU allows it (it's only one byte bigger than
>    IP6_MAX_MTU, 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.
> 
> The original overflow bug with IPv6 and IPV6_PMTUDISC_DO seems to
> predate git history (verified reproduction on 2.6.21), was fixed later,
> and then reappeared in commit 427faee167bc ("net: ipv6: introduce
> ip6_dst_mtu_maybe_forward"), which is chosen as the Fixes tag here. The
> overflow with IPV6_PMTUDISC_PROBE reproduces since its introduction in
> commit 628a5c561890 ("[INET]: Add IP(V6)_PMTUDISC_RPOBE").
> 
> Fixes: 427faee167bc ("net: ipv6: introduce ip6_dst_mtu_maybe_forward")
> 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: Codex:gpt-5.6-sol
> Cc: Willem de Bruijn <willemdebruijn.kernel@gmail.com>

Reviewed-by: Willem de Bruijn <willemb@google.com>