CVE-2026-80925 in Linux
Summary
by MITRE • 09/09/2026
In the Linux kernel, the following vulnerability has been resolved:
vlan: fix skb_under_panic and races when toggling HW VLAN offload
Toggling hardware VLAN TX offload (NETIF_F_HW_VLAN_CTAG_TX or NETIF_F_HW_VLAN_STAG_TX) on a lower device invokes vlan_transfer_features(), which dynamically changed vlandev->hard_header_len.
This causes two issues: 1. Lockless TX paths (e.g. packet_snd in af_packet.c, ip6_finish_output2) read dev->hard_header_len without holding RTNL lock. Mutating hard_header_len dynamically under RTNL creates a data race where upper layers reserve insufficient headroom based on a stale hard_header_len, resulting in skb_under_panic when vlan_dev_hard_header() is called. 2. In addition, vlan_transfer_features() updated hard_header_len without updating header_ops, causing a mismatch between allocated headroom and header creation.
Always setting dev->hard_header_len = real_dev->hard_header_len and dev->needed_headroom = real_dev->needed_headroom + VLAN_HLEN unconditionally ensures: - dev->hard_header_len remains 100% static and immutable at real_dev->hard_header_len, eliminating all dynamic runtime updates and data races on hard_header_len. - Upper layers allocating skbs via LL_RESERVED_SPACE() will always reserve sufficient headroom for software VLAN tag insertion (real_dev->hard_header_len + real_dev->needed_headroom + VLAN_HLEN). - vlandev inherits real_dev->needed_tailroom so underlying trailer/padding/ICV requirements are honored. - AF_PACKET SOCK_RAW network header offsets remain correctly aligned at real_dev->hard_header_len. - vlan_header_ops is used unconditionally.
Note to stable teams: Make sure to backport these commits:
e16e960d55a4 ("ipvlan: inherit needed_headroom and needed_tailroom from phy_dev") cef51860becd ("macvlan: inherit needed_headroom and needed_tailroom from lowerdev")
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 09/09/2026
The Linux kernel vulnerability involving the Virtual Local Area Network subsystem presents a critical flaw in how hardware VLAN offload features are managed during runtime configuration changes. Specifically, toggling hardware VLAN TX offload capabilities on a lower network device triggers the vlan_transfer_features function, which dynamically modifies the vlandev->hard_header_len field. This dynamic mutation of header length parameters introduces severe concurrency issues and memory management errors that can lead to kernel panics or data corruption under specific traffic conditions. The root cause lies in the interaction between lockless transmission paths and mutable device configuration structures, creating a scenario where network stack components operate on stale or inconsistent state information regarding packet buffer requirements.
The primary technical flaw involves a race condition within lockless Transmission Control Block processing paths such as packet_snd in af_packet.c and ip6_finish_output2 for IPv6 traffic. These high-performance code paths read the dev->hard_header_len value without acquiring the RTNL lock, which is typically required to serialize configuration changes. When vlan_transfer_features mutates hard_header_len dynamically while these lockless paths are executing concurrently, a data race occurs. Upper network layers allocate socket buffer headroom based on a stale or incorrect hard_header_len value that does not reflect the current requirement for VLAN tag insertion. Consequently, when vlan_dev_hard_header is subsequently called to construct the packet header, it attempts to write beyond the allocated memory boundaries of the sk_buff structure. This out-of-bounds access triggers an skb_under_panic condition, resulting in a kernel crash and potential denial of service for the affected system or virtual machine instance hosting the network interface.
A secondary but equally critical issue arises from the mismatch between allocated headroom and header creation logic within vlan_transfer_features. The function updates hard_header_len without correspondingly updating the associated header_ops structure. This inconsistency means that even if memory allocation were somehow sufficient, the actual mechanism for constructing headers would be misaligned with the reserved space expectations of upper layers. The lack of synchronization between these two configuration parameters creates a structural integrity failure within the network stack's packet processing pipeline. By failing to maintain consistency between allocated resources and operational logic, the kernel exposes itself to undefined behavior that can compromise system stability and security posture during normal network interface reconfiguration events.
The resolution implements a strategy of enforcing static immutability for hard_header_len by unconditionally setting dev->hard_header_len equal to real_dev->hard_header_len. This approach eliminates all dynamic runtime updates to the header length field, thereby removing the window of opportunity for data races on this critical variable. Furthermore, dev->needed_headroom is set to real_dev->needed_headroom plus VLAN_HLEN, ensuring that upper layers allocating socket buffers via LL_RESERVED_SPACE always reserve sufficient headroom for software VLAN tag insertion regardless of offload state changes. This guarantees that memory allocation aligns precisely with the actual requirements for header construction and payload placement.
In addition to fixing the race condition, the patch ensures proper inheritance of tail room parameters from the physical device. By setting dev->needed_tailroom equal to real_dev->needed_tailroom, the solution honors underlying trailer, padding, and Integrity Check Value requirements mandated by specific hardware or protocol standards. This comprehensive adjustment also maintains correct alignment for AF_PACKET SOCK_RAW network header offsets at real_dev->hard_header_len, preserving compatibility with applications that rely on precise memory layout expectations. The unconditional use of vlan_header_ops further standardizes the packet processing path, reducing complexity and potential points of failure in header manipulation logic.
From a vulnerability classification perspective, this issue maps to CWE-362 Concurrent Execution using Shared Resource with Improper Synchronization, specifically highlighting the race condition on shared kernel data structures without adequate locking mechanisms. It also relates to CWE-119 Improper Restriction of Operations within the Bounds of a Memory Buffer due to the skb_under_panic resulting from insufficient headroom allocation. In terms of adversary behavior and detection frameworks, this vulnerability aligns with ATT&CK technique T1498 Network Denial of Service, as successful exploitation can lead to kernel panics that disrupt network availability. The fix ensures resilience against both accidental triggers through rapid interface toggling and potential malicious attempts to exploit timing windows for denial-of-service attacks.
For stable tree maintenance teams, it is imperative to backport specific commits e16e960d55a4 regarding ipvlan inheritance of needed_headroom and tailroom from the physical device, as well as cef51860becd concerning macvlan inheritance patterns. These foundational changes support the broader fix by ensuring that virtual network devices correctly propagate resource requirements from their underlying physical counterparts. This holistic approach to memory management and synchronization prevents similar race conditions across different types of VLAN implementations within the kernel. Administrators should apply these patches promptly to mitigate risks associated with dynamic interface configuration, particularly in environments where hardware offload features are frequently toggled or automated through orchestration tools that modify network settings on the fly.