CVE-2026-97984 in Linux
Summary
by MITRE • 09/25/2026
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 IP6_MAX_MTU for UDP sockets to avoid a 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.
To avoid breaking sending UDP jumbograms over raw IPv6 sockets, limit the change to UDP sockets only.
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").
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/25/2026
The Linux kernel contains a critical vulnerability within the IPv6 networking stack that allows for an integer overflow in UDP packet length fields, potentially leading to network instability or denial of service conditions. This flaw specifically affects systems where Path Maximum Transmission Unit discovery is enabled and configured with strict probing modes. The issue arises when a user-space application sends large UDP packets over a network interface configured with an MTU larger than the standard IPv6 maximum transmission unit limit. Under these specific conditions, the kernel fails to properly bound the fragmentation size, resulting in a calculated packet length that exceeds the capacity of the 16-bit unsigned integer field used for UDP lengths. This overflow causes the actual transmitted or processed data structure to wrap around, creating malformed packets that can disrupt network operations and trigger internal kernel warnings indicative of severe logic errors.
The technical root cause lies in how the IPv6 corking mechanism handles packet assembly when Path MTU discovery is active with specific settings such as IPV6_PMTUDISC_DO or IPV6_PMTUDISC_PROBE. When these socket options are set, the kernel allows the maximum non-fragmented size to be determined by the underlying network device's MTU rather than being capped at IP6_MAX_MTU. If a large payload is sent that fits within this larger device MTU but exceeds standard IPv6 limits, the resulting UDP length calculation can reach values like 65536 bytes when combined with headers. Since the UDP header uses a 16-bit field for its length indicator, which has a maximum value of 65535, any value equal to or exceeding this threshold causes an integer overflow. This results in a zero or near-zero length being recorded in the packet structure, effectively corrupting the data integrity and triggering defensive checks within the kernel such as udp_set_len_short, which logs warnings about invalid lengths.
From a security perspective, this vulnerability is classified under CWE-190 Integer Overflow or Wraparound, specifically affecting network protocol implementation details. It also aligns with ATT&CK technique T1498 Network Denial of Service, particularly sub-technique T1498.002 Resource Exhaustion via Flooding, as the malformed packets can cause receivers to drop traffic or trigger kernel-level error handling that consumes system resources. The vulnerability has historical precedence in Linux networking code and was previously addressed before being reintroduced through subsequent refactoring commits related to IPv6 destination route caching and forwarding logic. Its persistence indicates a systemic issue in how large packet sizes are validated against protocol constraints when path discovery mechanisms override default size limits.
The operational impact of this flaw includes the potential for local denial of service if an attacker can induce the sending of such oversized packets, causing kernel warnings that may degrade performance or stability on affected systems. While it does not directly allow remote code execution due to the nature of the overflow being in a length field rather than memory addresses, it compromises network reliability and integrity. The vulnerability is limited to UDP sockets over IPv6 with specific MTU discovery settings, meaning TCP connections and other protocols are unaffected by this particular flaw. However, for applications relying on large datagram transfers or high-throughput UDP communications over networks with non-standard MTUs, the risk of packet corruption and connection instability remains significant until patched.
Mitigation strategies primarily involve applying kernel updates that include the fix to bound cork->base.fragsize to IP6_MAX_MTU for all UDP sockets regardless of device configuration. Administrators should ensure their systems are updated to versions containing this correction. In environments where immediate patching is not feasible, limiting the MTU of network interfaces to standard IPv6 limits or disabling IPV6_PMTUDISC_PROBE and IPV6_PMTUDISC_DO settings can serve as temporary workarounds to prevent the overflow condition from being triggered. Additionally, monitoring for kernel warnings related to UDP length validation in system logs can help identify instances where this vulnerability is being exploited or inadvertently triggered by legitimate traffic patterns exceeding standard limits.