CVE Catalog

CVE-2026-98393

Unknown
Published: Translated: NVD NIST

Summary

In the Linux kernel IPv4 handling, a UDP length overflow occurs with PMTU discovery and a very large interface MTU. When IP_MTU_DISCOVER is set to IP_PMTUDISC_PROBE and a packet is sent over a netdev with MTU larger than IP_MAX_MTU + 20, the UDP length can exceed the 16-bit field and trigger a WARN in udp_set_len_short. This affects the IPv4 networking stack in the kernel.

Risk Assessment

Can trigger kernel warnings and potentially lead to system instability or denial of service in environments with unusually large MTU. However, it requires a specific configuration (IP_PMTUDISC_PROBE and very large MTU).

Recommendation

Update the Linux kernel to a version containing the fix that bounds cork->base.fragsize to IP_MAX_MTU. Avoid setting IP_MTU_DISCOVER to IP_PMTUDISC_PROBE on interfaces with MTU larger than IP_MAX_MTU + 20.

Other vulnerabilities in Linux kernel

See all
Original NVD description (English source)

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 IP_MAX_MTU to avoid a possible overflow of UDP length that triggers a WARN in udp_set_len_short when setsockopt IP_MTU_DISCOVER is set to IP_PMTUDISC_PROBE, and a large packet is sent over a netdev with an unusually large MTU. Steps to reproduce: 1. Set device MTU bigger than IP_MAX_MTU + 20. cork->base.fragsize will be set to that MTU in ip_setup_cork. 2. Set IP_MTU_DISCOVER to IP_PMTUDISC_PROBE. It lets maxnonfragsize be set to device MTU (cork->fragsize) in __ip_append_data, rather than to IP_MAX_MTU. 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 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. 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. The Fixes tag points at the first commit where I could reproduce the overflow with IPv4 and IP_PMTUDISC_PROBE.

Vulnerability data from NVD (NIST) · CISA KEV · EPSS