CVE-2026-80978: net: cap advertised IP tunnel headroom
In the Linux kernel, the following vulnerability has been resolved:
net: cap advertised IP tunnel headroom
IP tunnel devices derive their advertised neededheadroom 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 neededheadroom at 512. Apply the same cap when tunnel configuration publishes neededheadroom 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.
Affected Software
Event History
Frequently Asked Questions
Which systems are realistically exposed to this issue?
Systems using user-created stacks of IP tunnel devices are the relevant exposure. The problematic condition requires a stacked tunnel configuration whose derived headroom grows beyond what 16-bit skb header offsets can represent.
What does an attacker or user need to do to trigger it?
They need to create a nonsensical stack of network devices that causes an IP tunnel to advertise an excessively large needed_headroom value inherited from a lower output device. The provided information does not establish whether this can be done by an unprivileged user.
What is the mitigation if the update cannot be applied immediately?
Avoid creating or permitting deeply stacked IP tunnel and other user-created network-device configurations that can cause derived tunnel headroom to grow without bound. The corrected behavior caps advertised tunnel needed_headroom at 512 while allowing transmit-time skb expansion when additional space is actually required.