CVE-2026-97984: net: ipv6: Fix UDP length overflow with PMTU discover and big MTU
In the Linux kernel, the following vulnerability has been resolved:
net: ipv6: Fix UDP length overflow with PMTU discover and big MTU
This commit bounds cork->base.fragsize to IP6MAXMTU for UDP sockets to avoid a possible overflow of UDP length that triggers a WARN in udpsetlenshort when setsockopt IPV6MTUDISCOVER is set to IPV6PMTUDISCDO or IPV6PMTUDISCPROBE, 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 IP6MAXMTU. cork->base.fragsize will be set to that MTU in ip6setupcork. 2. Set IPV6MTUDISCOVER to IPV6PMTUDISCPROBE or IPV6PMTUDISCDO. It lets maxnonfragsize be set to device MTU (cork->fragsize) in ip6appenddata, rather than to IP6MAXMTU. 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 IP6MAXMTU, 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 udpsetlenshort.
To avoid breaking sending UDP jumbograms over raw IPv6 sockets, limit the change to UDP sockets only.
The original overflow bug with IPv6 and IPV6PMTUDISCDO seems to predate git history (verified reproduction on 2.6.21), was fixed later, and then reappeared in commit 427faee167bc ("net: ipv6: introduce ip6dstmtumaybeforward"), which is chosen as the Fixes tag here. The overflow with IPV6PMTUDISCPROBE reproduces since its introduction in commit 628a5c561890 ("[INET]: Add IP(V6)PMTUDISCRPOBE").
Affected Software
Event History
Frequently Asked Questions
Which systems are exposed to this condition?
Systems are affected when a UDP socket sends over an IPv6 network device whose MTU is larger than IP6_MAX_MTU. The socket must use IPV6_MTU_DISCOVER set to IPV6_PMTUDISC_DO or IPV6_PMTUDISC_PROBE.
What action is required to trigger the warning?
A sender must transmit 65,528 bytes of UDP payload under the affected PMTU-discovery settings on a device with a sufficiently large MTU. With the UDP and IPv6 headers, the resulting UDP length becomes 65,536 and overflows the 16-bit UDP length field.
How can an administrator identify an affected configuration?
Check for IPv6-capable interfaces configured with an MTU greater than IP6_MAX_MTU, and identify UDP applications that set IPV6_MTU_DISCOVER to IPV6_PMTUDISC_DO or IPV6_PMTUDISC_PROBE. The affected condition produces a WARN in udp_set_len_short.
Does the fix affect raw IPv6 UDP jumbogram use?
The change is limited to UDP sockets specifically to avoid breaking UDP jumbograms sent over raw IPv6 sockets.