CVE-2026-80978
massLinux kernel: stacked IP tunnel headroom overflow wraps skb offsets (local corruption)
The Linux kernel fails to cap the needed_headroom value that IP tunnel devices advertise to upper layers when it is derived from a lower output device, so a stack of user-created tunnel devices can drive that value beyond what 16-bit skb header offsets can represent. Once IP output reserves the oversized headroom, skb head expansion can wrap those offsets, corrupting kernel packet buffer bookkeeping. A local attacker who can create network devices (e.g., via CAP_NET_ADMIN or unprivileged user namespaces) could exploit this for kernel memory corruption, enabling privilege escalation or denial of service, reflected in a CVSS 3.1 score of 7.8 with high confidentiality, integrity, and availability impact. Any system running an unpatched kernel containing the uncapped advertisement logic is affected, though exploitation requires local access and the ability to stack tunnel devices. There is no known public proof of concept and no evidence of in-the-wild exploitation; the flaw is not in the CISA KEV catalog.
What to do: Apply kernel updates from your distribution once they include the fix that caps tunnel-advertised needed_headroom at 512 bytes, and prioritize multi-tenant or user-facing Linux hosts. As defense in depth, restrict CAP_NET_ADMIN and consider disabling unprivileged user namespaces (e.g., sysctl user.max_user_namespaces=0) on systems where untrusted local users exist. Watch for unexpected creation or stacking of IP tunnel devices (ip tunnel / netlink events) as a possible precursor to exploitation attempts.
| Linux kernel | — |
Order-of-magnitude estimate by the model from install counts, market share and public scan data it knows; verify before quoting.
In the Linux kernel, the following vulnerability has been resolved: net: cap advertised IP tunnel headroom IP tunnel devices derive their advertised needed_headroom from lower output devices. A stack of user-created devices can make the derived value larger than the 16-bit skb header offsets can represent. Once IP output reserves it, skb head expansion can wrap those offsets. The runtime transmit path already caps a growing needed_headroom at 512. Apply the same cap when tunnel configuration publishes needed_headroom derived from a lower output device. Capping the advertised value is safe: IP tunnel transmit still expands the skb when a packet needs more headroom. A nonsensical stacked configuration can therefore incur an extra reallocation, but it cannot publish an unbounded reservation to upper layers.
- Vector
- CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
In the news0 stories
No ingested article mentions this CVE yet.