HIGH Introduced in 3.11
net TunnelHeadroom Overflow
CVE-2026-80978
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
KernelScan AI8.5HIGH
01Description
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.
02KernelScan AI Analysis
Risk summary
A local user who can create network namespaces (including unprivileged users via user namespaces) can stack IP tunnel devices to inflate the advertised headroom beyond what 16-bit skb header offsets can represent. When packets are transmitted, the wrapped offsets corrupt kernel memory, enabling privilege escalation or container escape. Any system allowing untrusted local users or container workloads with user namespace support is at risk.
Vulnerability analysis
IP tunnel devices publish a headroom requirement based on the underlying device beneath them. By stacking multiple tunnel devices, an attacker can inflate that requirement beyond what the kernel's internal packet-buffer counters can represent. When the kernel later reserves space for a transmitted packet, those counters wrap and corrupt buffer metadata, causing memory corruption. The fix limits the published requirement to 512 bytes whenever tunnel configuration derives it from a lower device, matching the limit already enforced during live transmission. The transmit logic still grows buffers on demand if a packet truly needs more space, so normal traffic is unaffected. Any local user who can create tunnel devices can reach this path, and unprivileged users gain that ability through user namespaces.
Lifecycle
03Fix Versions
| Branch | Introduced | Fixed in | Patch commit |
|---|---|---|---|
| 5.10 | 3.11 | 5.10.270 | fb889a619723 |
| 5.15 | 3.11 | 5.15.221 | b160422f8103 |
| 6.1 | 3.11 | 6.1.188 | d36e75f56691 |
| 6.12 | 3.11 | 6.12.109 | bc4e05ae66c9 |
| 6.18 | 3.11 | 6.18.50 | af0ee8f04bea |
| 6.6 | 3.11 | 6.6.157 | 84783961cb8b |
| 7.2 | 3.11 | 7.2.4 | 9144f2c53a04 |
| mainline | 3.11 | 7.3 | 6b222adeb934 |
| cip/5.10 | 3.11 | 5.10.271-cip78 | fb889a619723 |
| cip/6.1 | 3.11 | 6.1.189-cip61 | d36e75f56691 |
| cip/6.1-rt | 3.11 | 6.1.189-cip61-rt32 | d36e75f56691 |
| cip/6.12 | 3.11 | 6.12.111-cip32 | bc4e05ae66c9 |
04CIP Kernels
State of the newest release of each Civil Infrastructure Platform SLTS tree, from CIP's own fix records.
| CIP tree | State |
|---|---|
| cip/6.12 | Fixed in 6.12.111-cip32 |
| cip/6.1 | Fixed in 6.1.189-cip61 |
| cip/6.1-rt | Fixed in 6.1.189-cip61-rt32 |
| cip/5.10 | Fixed in 5.10.271-cip78 |
| cip/5.10-rt | Affected — no CIP fix yet (latest 5.10.268-cip77-rt34) |
| cip/4.19 | Affected — no CIP fix yet (latest 4.19.325-cip136) |
| cip/4.19-rt | Affected — no CIP fix yet (latest 4.19.325-cip136-rt50) |
| cip/4.4 | Affected — no CIP fix yet (latest 4.4.302-cip115) |
| cip/4.4-rt | Affected — no CIP fix yet (latest 4.4.302-cip115-rt63) |