CVE-2026-80793: Linux Kernel IPv4 Fragmentation DOS Vulnerability

CVE-2026-80793 Overview

CVE-2026-80793 is a denial-of-service vulnerability in the Linux kernel's IPv4 fragmentation path. The flaw resides in ip_do_fragment(), which subtracts the IPv4 header length from the effective MTU before passing the payload MTU to ip_frag_next(). When the effective MTU is smaller than hlen + 8, the fragment payload length rounds down to zero. Fragmentation state never advances, and the kernel loops indefinitely allocating and transmitting header-only fragments until the softlockup detector triggers. The condition is reachable through routes installed with mtu lock 20 or by forwarding packets to a device configured with a 20-byte MTU.

Critical Impact
A local or adjacent attacker capable of configuring a route or influencing egress device MTU can trigger a kernel softlockup, disrupting host availability.

Affected Products

Linux kernel (IPv4 fragmentation subsystem, net/ipv4/ip_output.c)
Distributions shipping vulnerable stable kernels prior to the referenced fix commits
Systems performing IPv4 forwarding or routing over interfaces with low MTU values

Discovery Timeline

2026-09-04 - CVE-2026-80793 published to NVD
2026-09-04 - Last updated in NVD database

Technical Details for CVE-2026-80793

Vulnerability Analysis

The defect is a resource exhaustion condition in the IPv4 output path. ip_do_fragment() computes the per-fragment payload size by subtracting the IPv4 header length (hlen) from the effective MTU. ip_frag_next() then aligns the payload size, but when the effective MTU is less than hlen + 8, the resulting length rounds down to zero. Each iteration produces a header-only skb, transmits it, and leaves the fragmentation cursor (state->left, state->ptr, state->offset) unchanged. The loop never terminates on its own, and the kernel's softlockup watchdog eventually fires.

The fix rejects any request where mtu < hlen + 8 by returning -EMSGSIZE, mirroring the equivalent guard already present in the IPv6 fragmentation code path.

Root Cause

The root cause is missing input validation on the effective MTU inside ip_do_fragment() before deriving the payload MTU. The function trusted the caller-supplied MTU to be at least large enough to hold an IPv4 header plus the 8-byte minimum fragment payload required by RFC 791. No lower bound check existed, allowing a degenerate MTU to produce a zero-length payload window and a non-progressing fragmentation loop.

Attack Vector

Exploitation requires the ability to influence the effective MTU used when transmitting an IPv4 packet through the affected host. Two reproduction paths are documented in the upstream commit message: installing a route with ip route add ... mtu lock 20, or forwarding a packet to an interface whose MTU has been set to 20. On multi-tenant systems where unprivileged network namespaces expose routing configuration, or in forwarding scenarios where a downstream interface MTU can be manipulated, this results in a CPU-bound softlockup and denial of service on the affected core.

No verified public exploit code has been published. Refer to the upstream commits linked below for the corrective patch and the exact fragmentation logic:

Detection Methods for CVE-2026-80793

Indicators of Compromise

Kernel log entries reporting watchdog: BUG: soft lockup - CPU#N stuck originating from ip_do_fragment or ip_frag_next stack frames.
Sustained 100% CPU utilization on a single core with kernel-mode time dominating user-mode time on hosts performing IPv4 forwarding.
Unusual routing configuration changes containing mtu lock values below 28 bytes, or interface MTU changes to values under 28 bytes.

Detection Strategies

Audit routing tables for entries with mtu lock values below the IPv4 minimum by parsing ip route show output on managed hosts.
Monitor dmesg and journalctl -k for softlockup traces referencing IPv4 fragmentation symbols.
Correlate network configuration events (netlink RTM_NEWROUTE, RTM_SETLINK) with subsequent CPU spikes to identify malicious MTU manipulation.

Monitoring Recommendations

Ship kernel messages and audit logs to a centralized SIEM and alert on soft lockup signatures tied to networking symbols.
Track per-CPU softirq and system CPU time; sustained saturation on forwarding hosts warrants investigation.
Restrict and log CAP_NET_ADMIN usage inside network namespaces to detect unauthorized route or link MTU modifications.

How to Mitigate CVE-2026-80793

Immediate Actions Required

Apply the stable kernel updates referenced in the upstream commits as soon as vendor packages are available for your distribution.
Inventory hosts that perform IPv4 forwarding and prioritize patching for routers, gateways, and container hosts.
Remove or reject any existing routes that specify mtu lock values below 68 bytes, the IPv4 minimum reassembly buffer size.

Patch Information

The upstream fix adds a check in ip_do_fragment() that returns -EMSGSIZE when mtu < hlen + 8, matching the existing IPv6 fragmentation guard. Corrective commits include 3556beb8, 36e07418, 515b6816, 74ce7389, a716a64a, b0ea9114, c0726f0c, c8a74adc, and d9d1a676. Consult your distribution's security tracker to identify the backported package version.

Workarounds

Restrict CAP_NET_ADMIN inside unprivileged user namespaces via sysctl -w kernel.unprivileged_userns_clone=0 where operationally acceptable.
Enforce a minimum MTU policy on managed interfaces and reject route installations with abnormally low mtu values through configuration management.
Disable IPv4 forwarding on hosts that do not require it using sysctl -w net.ipv4.ip_forward=0.

bash

# Configuration example: audit routes for undersized MTU locks
ip -4 route show | awk '/mtu lock/ && $NF+0 < 68 {print "Suspect route:", $0}'

# Disable IPv4 forwarding where not required
sysctl -w net.ipv4.ip_forward=0

# Restrict unprivileged network namespace creation
sysctl -w kernel.unprivileged_userns_clone=0