CVE-2026-80978 in Linux
Summary
by MITRE • 09/12/2026
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.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/12/2026
The Linux kernel network stack contains a vulnerability related to how Internet Protocol (IP) tunnel devices calculate and advertise the required header room for packet buffers. This issue stems from the mechanism by which IP tunnels determine their needed_headroom, which is derived dynamically from the lower output devices in the networking configuration. When multiple layers of user-created virtual network interfaces are stacked together, this derivation process can result in a cumulative headroom requirement that exceeds the capacity of 16-bit signed integer offsets used within the socket buffer structure. This architectural limitation creates a scenario where the calculated value becomes excessively large, potentially leading to arithmetic overflow or wraparound effects when the IP output layer attempts to reserve space for headers during packet transmission.
The core technical flaw lies in the absence of an upper bound check on the advertised needed_headroom before it is published to higher layers of the network stack. While the runtime transmit path already includes logic to cap a growing needed_headroom at 512 bytes, this safeguard was not applied consistently when tunnel configuration initially publishes its derived headroom requirements from lower devices. Consequently, if an attacker or misconfigured system creates a deeply nested chain of virtual interfaces with high header overheads, the resulting advertised value can surpass the limits supported by the underlying data structures. This discrepancy allows for potential memory corruption issues due to integer wraparound when the kernel attempts to expand the socket buffer head based on these inflated values.
From an operational perspective, this vulnerability poses a risk of denial of service and potentially remote code execution if exploited in conjunction with other vulnerabilities. The immediate impact is that packets processed through such misconfigured tunnel stacks may trigger unexpected behavior due to incorrect memory allocation sizes. Although the runtime transmit path eventually caps headroom at 512 bytes during actual transmission, the initial publication of an unbounded or excessively large value can still cause issues in upper-layer processing logic that relies on these advertised constraints for buffer management and security checks. The vulnerability highlights a critical gap between configuration-time validation and runtime enforcement mechanisms within the kernel networking subsystem.
The resolution involves applying the same 512-byte cap to the needed_headroom when it is published during tunnel configuration, ensuring consistency with the runtime transmit path behavior. This capping strategy is considered safe because IP tunnel transmission logic retains the ability to expand socket buffers dynamically if a packet requires more headroom than advertised. Therefore, while an excessively stacked or nonsensical network configuration might incur additional memory reallocation overhead due to conservative initial reservations, it will not result in unbounded reservation requests that could destabilize system resources. This fix effectively neutralizes the risk of integer wraparound and ensures predictable buffer management across complex virtual networking topologies.
This vulnerability aligns with CWE-190 Integer Overflow or Wraparound, as the primary failure mode involves arithmetic limits being exceeded due to unchecked accumulation of header requirements. It also relates to CWE-20 Improper Input Validation, specifically regarding the lack of boundary checks on derived configuration parameters before they are propagated through system layers. In terms of MITRE ATT&CK mapping, this type of issue can be associated with T1564 Hidden Processes and Files or more broadly within privilege escalation vectors if memory corruption leads to arbitrary code execution, though its primary classification remains a stability and integrity flaw in network stack handling. Mitigation requires applying the kernel patch that enforces headroom caps during configuration phases, thereby preventing the propagation of invalid buffer size requests through the networking subsystem.