CVE-2026-81000: net: tun: bound receive headroom
In the Linux kernel, the following vulnerability has been resolved:
net: tun: bound receive headroom
tungetuser() uses tun->align both as skb headroom and when choosing how much packet data to keep linear. OVS can propagate an oversized headroom request from another port to TUN or TAP.
When align is larger than the usable space in a one-page skb head, SKBMAXHEAD(align) underflows and the result becomes negative when stored in goodlinear. That value later wraps when assigned to the sizet linear variable, and tunallocskb() can place skb->data outside the allocated head.
Bound the headroom stored by TUN to the one-page skb-head budget and the largest non-sentinel 16-bit skb header offset. Leave one linear byte for raw TUN and a complete Ethernet header for TAP, including NETIPALIGN.
Also pull the raw-TUN protocol byte and the TAP Ethernet header before accessing them, so these checks remain safe for nonlinear skbs supplied by other allocation paths.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Compensating control
If using TUN/TAP with OVS, ensure traffic to raw-TUN (protocol byte) and TAP (complete Ethernet header including NET_IP_ALIGN) is handled with adequate linear headroom so oversized headroom propagation via OVS does not cause skb headroom underflow/wrap.
Event History
Frequently Asked Questions
What configurations are exposed to this issue?
Systems using Linux TUN or TAP devices are relevant, particularly where Open vSwitch can propagate an oversized receive-headroom request from another port to a TUN or TAP device. The described path involves one-page skb heads and an align value exceeding their usable headroom budget.
What does an attacker or triggering workload need to control?
The triggering condition is an oversized headroom request that reaches TUN or TAP, causing the computed linear-data amount to underflow and later wrap. The description specifically identifies Open vSwitch as a path that can propagate such a request from another port.
What is the impact of successful triggering?
The wrapped linear size can cause tun_alloc_skb() to place skb->data outside the allocated skb head. This is an out-of-bounds memory placement condition in the kernel networking path.
What mitigation is available if an update cannot be applied immediately?
The available data does not provide a complete workaround. Reducing exposure means avoiding configurations in which Open vSwitch or another input can send oversized headroom requests to TUN or TAP devices.