CVE-2026-80793 in Linux
Summary
by MITRE • 09/04/2026
In the Linux kernel, the following vulnerability has been resolved:
ipv4: reject undersized MTUs in ip_do_fragment()
ip_do_fragment() subtracts the IPv4 header length from the effective MTU and passes the resulting payload MTU to ip_frag_next().
If the effective MTU is smaller than hlen + 8, ip_frag_next() rounds the fragment payload length down to zero. The fragmentation state then never makes forward progress: state->left, state->ptr and state->offset stay unchanged while ip_do_fragment() keeps allocating and transmitting header-only fragments until the softlockup detector fires.
This is reproducible with a route installed using "mtu lock 20", but it is also reproducible without route MTU lock, for example by forwarding a packet to a device whose MTU is 20.
Fix it in ip_do_fragment() by rejecting mtu < hlen + 8 with -EMSGSIZE, matching the existing IPv6 fragmentation check.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/04/2026
The Linux kernel contains a critical logic flaw within the IPv4 packet fragmentation subsystem that can lead to denial of service conditions through soft lockups. The vulnerability resides in the ip_do_fragment function, which is responsible for breaking large IP packets into smaller fragments when they exceed the Maximum Transmission Unit MTU of the outgoing network interface. During this process, the kernel calculates the effective payload size by subtracting the IPv4 header length from the configured MTU and passes this value to subsequent fragmentation handling routines. The core issue arises when the effective MTU is excessively small, specifically smaller than the sum of the IP header length plus eight bytes. In such scenarios, the downstream ip_frag_next function attempts to round down the fragment payload length to zero because there is insufficient space for even a minimal data segment alongside required headers and alignment padding.
This miscalculation triggers an infinite loop within the fragmentation state machine. Because the calculated payload size becomes zero or negative, the internal counters tracking remaining bytes left to transmit, current pointer position, and offset remain unchanged after each iteration. Consequently, ip_do_fragment continues to allocate memory for new fragments that contain only headers and no actual data payload. These empty header-only packets are transmitted repeatedly without any progress toward completing the fragmentation process. This behavior consumes CPU cycles indefinitely until the kernel softlockup detector intervenes by triggering a watchdog timeout or panic, effectively causing a denial of service for the affected system or network path.
The vulnerability is reproducible under specific routing configurations where an MTU lock forces packets to adhere to unusually small size constraints, such as setting an MTU lock to twenty bytes. It can also be triggered in forwarding scenarios by directing traffic toward devices with similarly restrictive MTU settings. The lack of validation allows malformed or adversarially crafted network paths to exploit this logic error, leading to system instability and potential service disruption for any host relying on the compromised kernel instance. This represents a significant reliability issue particularly for routers and gateways that handle diverse network topologies with varying MTU requirements.
To mitigate this vulnerability, the fix involves adding an explicit validation check within ip_do_fragment before proceeding with fragmentation logic. The function now rejects packets where the effective MTU is less than the header length plus eight bytes by returning an EMSGSIZE error code. This approach aligns the IPv4 behavior with existing IPv6 fragmentation checks, ensuring consistent handling of undersized paths across both protocol versions. By rejecting these invalid configurations early in the processing pipeline, the kernel prevents the allocation of unnecessary resources and avoids entering the infinite loop state that leads to soft lockups.
From a security taxonomy perspective, this flaw is classified under CWE-835 which relates to loops with unreachable exit conditions or resource exhaustion due to logic errors. The attack vector involves manipulating network routing parameters or forwarding traffic through constrained interfaces to trigger the condition, mapping closely to ATT&CK technique T1499 Endpoint Denial of Service via service disruption. Administrators and system operators must ensure that kernel updates incorporating this patch are applied promptly to maintain network stability. Additionally, monitoring for soft lockup warnings in system logs can help identify instances where such conditions may have been attempted or exploited before the fix was deployed. Proper configuration management of MTU settings across network devices is also recommended to prevent accidental triggering of these edge cases during normal operations.