CVE-2026-98393: net: ipv4: Fix UDP length overflow with PMTU discover and big MTU
In the Linux kernel, the following vulnerability has been resolved:
net: ipv4: Fix UDP length overflow with PMTU discover and big MTU
This commit bounds cork->base.fragsize to IPMAXMTU to avoid a possible overflow of UDP length that triggers a WARN in udpsetlenshort when setsockopt IPMTUDISCOVER is set to IPPMTUDISCPROBE, and a large packet is sent over a netdev with an unusually large MTU.
Steps to reproduce:
1. Set device MTU bigger than IPMAXMTU + 20. cork->base.fragsize will be set to that MTU in ipsetupcork. 2. Set IPMTUDISCOVER to IPPMTUDISCPROBE. It lets maxnonfragsize be set to device MTU (cork->fragsize) in ipappenddata, rather than to IPMAXMTU. 3. Send 65528 bytes of payload (+8 bytes of UDP header, +20 bytes of IPv4 header). Device MTU allows it (it's only one byte bigger than IPMAXMTU + 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 udpsetlenshort.
Note: IPPMTUDISCDO with IPv4 is safe, because ipdstmtumaybeforward always clamps at IPMAXMTU, unlike ip6dstmtumaybeforward.
The Fixes tag points at the first commit where I could reproduce the overflow with IPv4 and IPPMTUDISCPROBE.
Affected Software
Event History
Frequently Asked Questions
What configuration is required to trigger this condition?
The sending application must set IP_MTU_DISCOVER to IP_PMTUDISC_PROBE, and traffic must use a network device whose MTU is larger than IP_MAX_MTU + 20.
What packet size triggers the overflow?
The documented reproduction sends 65,528 bytes of UDP payload. With the 8-byte UDP header, the UDP length becomes 65,536, which overflows the 16-bit UDP length field and triggers a WARN in udp_set_len_short.
Are systems using IP_PMTUDISC_DO affected in the same way?
No. The description states that IP_PMTUDISC_DO with IPv4 is safe because ip_dst_mtu_maybe_forward clamps the MTU at IP_MAX_MTU.
What can be done before applying the fix?
Avoid using IP_PMTUDISC_PROBE with interfaces configured above IP_MAX_MTU + 20, and do not send the documented oversized UDP payload under that configuration.