CVE-2026-80978

What it actually does

A local user can stack IP tunnel netdevices so advertised needed_headroom derived from lower devices exceeds what 16-bit skb header offsets can represent. After IP output reserves that value, skb head expansion wraps those offsets and corrupts kernel packet-buffer metadata, enabling out-of-bounds access, kernel panic, or further memory-safety abuse in the networking stack.

Why it matters to the business

Linux hosts that let untrusted users create or nest IP tunnels (including some container, CI, and multi-tenant systems) can suffer sudden kernel crashes, lost connectivity, or full host compromise from an existing local foothold. The issue is High impact (confidentiality, integrity, and availability) but is not in CISA KEV, has no known ransomware or in-the-wild use, exploit maturity is none, and EPSS remains very low and flat (~0.0018 over 30 days). Patch on a normal kernel-update cycle, with higher urgency on shared machines where unprivileged netdev creation is allowed.

How an attack unfolds

An attacker who already has local, low-privileged access and can create network interfaces (CAP_NET_ADMIN or equivalent, including some unprivileged user-namespace setups) builds a deep stack of user-created IP tunnel devices. Each layer inherits and inflates needed_headroom from the device below until the advertised reservation no longer fits in 16-bit skb offsets. Sending traffic through the stack causes IP output to reserve the oversized headroom; skb expansion then wraps header offsets and corrupts kernel memory, which the attacker uses for denial of service or as a primitive toward privilege escalation. No public exploit code or named threat-actor campaigns are known.

How to fix it

Install vendor Linux kernel updates that cap advertised IP-tunnel needed_headroom at 512 when publishing a value derived from a lower output device (the same cap the transmit path already applied to a growing reservation). Reboot into the patched kernel. Exact package versions were not listed with this record, so follow your distribution or kernel vendor advisory. Until patched, limit who can create tunnel and other virtual netdevices, constrain unprivileged user namespaces, and avoid deep stacks of user-created tunnels. Capping the advertised value is safe: transmit still expands the skb if more headroom is needed, at the cost of a possible extra reallocation on pathological stacks.

How to confirm the fix worked

Confirm the running kernel includes the change described as capping advertised IP tunnel headroom, via vendor changelog or kernel git history, then reboot and verify the running release. Review whether unprivileged users can create tunnels or nested netdevices. After the patch, tunnel traffic should still flow; a nonsensical stacked configuration may incur an extra reallocation but must not panic or wrap skb offsets.

Typical attack path

1. Obtain local access on a Linux host as a low-privileged user
2. Obtain the ability to create virtual network devices (network admin capability or equivalent namespace rights)
3. Create a nested stack of IP tunnel interfaces so advertised needed_headroom grows without bound
4. Cause packets to be transmitted so IP output reserves the oversized headroom and 16-bit skb offsets wrap
5. Abuse the resulting kernel memory corruption for a crash or further local privilege escalation

How to detect it

Hunt retrospectively in kernel logs (dmesg, journalctl --dmesg, kdump/vmcore, panic/oops collectors) for crashes whose call traces involve IP tunnels, skb head expansion, or offset wrap after nested tunnel creation. Correlate with netlink link-creation activity and capability or user-namespace use that adds many tunnel devices in a short window. There is no known in-the-wild campaign, so treat unexplained host panics on tunnel-heavy systems as the primary signal rather than malware hashes.

• Call trace containing ip_tunnel
• Call trace containing ip_tunnel_xmit
• Call trace containing iptunnel_xmit
• Call trace containing skb_cow_head
• Call trace containing skb_headroom
• kernel oops or panic in net/ipv4/ip_tunnel
• RTM_NEWLINK creating kind=ipip
• RTM_NEWLINK creating kind=gre
• RTM_NEWLINK creating kind=sit
• RTM_NEWLINK creating kind=vti
• Unable to handle kernel paging request

What your security team should do

• Patch and reboot Linux kernels, prioritizing multi-tenant, container, and developer hosts where untrusted users can create netdevices
• Restrict CAP_NET_ADMIN and unprivileged user namespaces where they are not required
• Inventory nested IP tunnel topologies and remove pathological stacks
• Watch kernel logs for oops/panic in the IP tunnel and skb head-expansion path
• Track distribution advisories for exact fixed package versions; this is not KEV-driven but should not be deferred on shared hosts