CVE-2026-80925

What it actually does

Dynamic mutation of dev->hard_header_len via vlan_transfer_features under RTNL creates data races in lockless TX paths (af_packet, ip6_finish_output2), allowing upper layers to reserve insufficient headroom based on stale values and triggering skb_under_panic in vlan_dev_hard_header; header_ops mismatch also occurs because hard_header_len changes without updating header creation logic.

Why it matters to the business

Unstable network stacks on Linux systems using VLAN devices can experience kernel panics during hardware offload toggling, leading to service disruption, connectivity loss, and potential downtime on servers or appliances handling VLAN traffic.

How an attack unfolds

An attacker with local or network access capable of toggling NETIF_F_HW_VLAN_CTAG_TX or STAG_TX on a lower device while concurrent lockless transmissions occur can induce the race; upper-layer skb allocation then under-reserves headroom, causing panic on header insertion. No public exploitation or threat actor campaigns are known.

How to fix it

Update to a kernel containing the fix that unconditionally sets dev->hard_header_len = real_dev->hard_header_len and dev->needed_headroom = real_dev->needed_headroom + VLAN_HLEN, and always uses vlan_header_ops. Backport commits e16e960d55a4 and cef51860becd to stable trees as noted in the advisory.

How to confirm the fix worked

Inspect kernel source for the static assignment of hard_header_len and needed_headroom from the real device, confirm vlan_header_ops is used unconditionally, and test that toggling HW VLAN offload no longer mutates these values or produces panics under concurrent TX load.

Typical attack path

1. Obtain ability to toggle hardware VLAN TX offload on a lower network device
2. Trigger concurrent lockless TX paths (e.g., raw sockets or IPv6 output) while the toggle occurs
3. Force upper layers to read stale hard_header_len and allocate undersized skbs
4. Invoke vlan_dev_hard_header to trigger skb_under_panic

How to detect it

Search system and kernel logs (dmesg, /var/log/kern.log, journalctl) for skb_under_panic, vlan_dev_hard_header, or hard_header_len races; correlate with ethtool or netlink events that toggle VLAN offload features around the time of the panic.

What your security team should do

• Prioritize kernel updates on systems exposing VLAN interfaces with hardware offload
• Review and restrict unprivileged access to ethtool or netlink interfaces that toggle offload features
• Monitor kernel logs for skb_under_panic and vlan-related oops until patched
• Consider disabling HW VLAN offload on lower devices where feasible as a temporary mitigation