CVE-2026-80925: vlan: fix skb_under_panic and races when toggling HW VLAN offload
In the Linux kernel, the following vulnerability has been resolved:
vlan: fix skbunderpanic and races when toggling HW VLAN offload
Toggling hardware VLAN TX offload (NETIFFHWVLANCTAGTX or NETIFFHWVLANSTAGTX) on a lower device invokes vlantransferfeatures(), which dynamically changed vlandev->hardheaderlen.
This causes two issues: 1. Lockless TX paths (e.g. packetsnd in afpacket.c, ip6finishoutput2) read dev->hardheaderlen without holding RTNL lock. Mutating hardheaderlen dynamically under RTNL creates a data race where upper layers reserve insufficient headroom based on a stale hardheaderlen, resulting in skbunderpanic when vlandevhardheader() is called. 2. In addition, vlantransferfeatures() updated hardheaderlen without updating headerops, causing a mismatch between allocated headroom and header creation.
Always setting dev->hardheaderlen = realdev->hardheaderlen and dev->neededheadroom = realdev->neededheadroom + VLANHLEN unconditionally ensures: - dev->hardheaderlen remains 100% static and immutable at realdev->hardheaderlen, eliminating all dynamic runtime updates and data races on hardheaderlen. - Upper layers allocating skbs via LLRESERVEDSPACE() will always reserve sufficient headroom for software VLAN tag insertion (realdev->hardheaderlen + realdev->neededheadroom + VLANHLEN). - vlandev inherits realdev->neededtailroom so underlying trailer/padding/ICV requirements are honored. - AFPACKET SOCKRAW network header offsets remain correctly aligned at realdev->hardheaderlen. - vlanheaderops is used unconditionally.
Note to stable teams: Make sure to backport these commits:
e16e960d55a4 ("ipvlan: inherit neededheadroom and neededtailroom from phydev") cef51860becd ("macvlan: inherit neededheadroom and neededtailroom from lowerdev")
Affected Software
Event History
Frequently Asked Questions
Which systems are exposed to this issue?
Linux systems using VLAN devices over a lower device where hardware VLAN TX offload is toggled are exposed. The affected offload features are NETIF_F_HW_VLAN_CTAG_TX and NETIF_F_HW_VLAN_STAG_TX.
What condition is required to trigger the failure?
Hardware VLAN TX offload must be changed on the lower device while lockless transmit paths can read the VLAN device's header length. A stale header-length value can cause insufficient skb headroom and lead to skb_under_panic during VLAN header creation.
Are ordinary VLAN transmit paths implicated?
Yes. The described lockless transmit examples include AF_PACKET packet_snd and IPv6 ip6_finish_output2, which read dev->hard_header_len without the RTNL lock.
What is the mitigation if the resolved change cannot be applied immediately?
Avoid toggling hardware VLAN TX offload on lower devices that have VLAN devices configured. This avoids the dynamic hard_header_len updates that create the race and header allocation mismatch.