Cloudanix VulnDB

CVE-2026-98554

None

CVSS

—

EPSS

0.2%

Published

Oct 18, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A flaw in how Linux handles certain network packets tagged with VLAN information can cause the entire system to crash.

Exploitation
Local Privilege
Attacker needs
Low Privilege
Complexity
Moderate
Impact
Denial Of Service
Component
OS kernel
Class
Memory Corruption
Remediation
Patch
Effort
Medium
Patch risk
Low

What it actually does

Insufficient headroom validation in vlan_dev_hard_header() allows skb_under_panic when callers reserve only ETH_HLEN or less, or when skbs predate dynamic headroom changes such as VLAN_FLAG_REORDER_HDR toggles or bonding/team slave switches; concurrent updates to hard_header_len and needed_headroom are read without READ_ONCE.

Why it matters to the business

Network-intensive Linux systems using VLANs, bonding, or teaming may experience unexpected kernel panics leading to service disruption and potential data loss; risk remains low given minimal EPSS and absence from known exploitation lists five days after disclosure.

How an attack unfolds

An attacker sends frames that reach vlan_dev_hard_header() via paths such as llc_alloc_frame() or under stacked VLAN configurations without sufficient headroom, or manipulates interface flags and slave devices to create skbs allocated before headroom adjustments, forcing the panic condition on transmit.

How to fix it

Upgrade to a Linux kernel containing the referenced commit that adds skb_cow_head() when VLAN_FLAG_REORDER_HDR is unset, uses READ_ONCE() for concurrent headroom fields, and avoids LL_RESERVED_SPACE to prevent unnecessary reallocations.

How to confirm the fix worked

Inspect kernel source or running version for presence of skb_cow_head() call and READ_ONCE() usage inside vlan_dev_hard_header(); reproduce with crafted skbs or flag toggles to confirm absence of under-panics.

Typical attack path

  1. Configure or discover a VLAN device with VLAN_FLAG_REORDER_HDR unset
  2. Arrange for an skb to be allocated with only ETH_HLEN or less headroom (e.g., via LLC or pre-change allocation)
  3. Trigger transmission that invokes vlan_dev_hard_header() without lock-held headroom updates
  4. Cause skb_under_panic and kernel crash

How to detect it

Search kernel logs and crash dumps for skb_under_panic triggered on transmit paths involving VLAN devices; correlate with recent VLAN flag changes, bonding slave switches, or LLC frame allocations.

What your security team should do

  • Apply the headroom fix to all VLAN-using kernels within standard patch windows
  • Monitor kernel logs for skb_under_panic entries involving vlan_dev_hard_header
  • Review bonding, teaming, and VLAN flag change procedures for headroom safety
  • Track EPSS and KEV updates for any rise in observed exploitation

The record

In the Linux kernel, the following vulnerability has been resolved: vlan: ensure sufficient headroom in vlan_dev_hard_header() Callers that only reserve ETH_HLEN or less (such as llc_alloc_frame()), or skbs allocated before dynamic device/headroom changes (e.g. toggling VLAN_FLAG_REORDER_HDR or bonding/team switching slaves), can reach vlan_dev_hard_header() with insufficient headroom and trigger skb_under_panic(). Use skb_cow_head() in vlan_dev_hard_header() when VLAN_FLAG_REORDER_HDR is not set to ensure sufficient headroom for the VLAN header(s) and the underlying device hard header. Use READ_ONCE() to read dev->hard_header_len and dev->needed_headroom as they can be updated concurrently under RTNL (e.g. in vlan_transfer_features()) while vlan_dev_hard_header() runs locklessly on the transmit path. Also avoid LL_RESERVED_SPACE(dev) here so that the extra HH_DATA_MOD alignment padding does not trigger unnecessary pskb_expand_head() reallocations on inner stacked VLAN devices after the outer VLAN header has been pushed.

Affected packages

Ecosystem Package Introduced Fixed