Skip to main content

Linux EUVDEUVD-2026-55591

| CVE-2026-68405
2026-08-10 Linux GHSA-qx36-wgrc-gggh

Lifecycle Timeline

2
Patch available
Aug 10, 2026 - 14:18 EUVD
CVE Published
Aug 10, 2026 - 12:04 cve.org
UNKNOWN (no severity yet)

DescriptionCVE.org

In the Linux kernel, the following vulnerability has been resolved:

wifi: mac80211: free AP_VLAN bc_buf SKBs outside IRQ lock

ieee80211_do_stop() removes AP_VLAN packets from the parent AP ps->bc_buf while holding ps->bc_buf.lock with IRQs disabled. It then calls ieee80211_free_txskb() before dropping the lock.

ieee80211_free_txskb() is not just a passive SKB release. For SKBs with TX status state it can report a dropped frame through cfg80211/nl80211, and that path can reach netlink tap transmit. This is the same reason the pending queue cleanup in ieee80211_do_stop() already unlinks SKBs under the queue lock and frees them after IRQ state is restored.

The buggy scenario involves two paths, with each column showing the order within that path:

AP_VLAN management TX: AP_VLAN stop:

  1. attach ACK-status state 1. clear the running state
  2. queue a multicast SKB on 2. take ps->bc_buf.lock with IRQs

parent ps->bc_buf disabled

  1. unlink the AP_VLAN SKB
  2. call ieee80211_free_txskb()

Unlink matching AP_VLAN SKBs from ps->bc_buf under the existing lock, but move them to a local free queue. Drop the lock and restore IRQ state before calling ieee80211_free_txskb().

WARNING: kernel/softirq.c:430 at __local_bh_enable_ip

Analysis

In the Linux kernel, the following vulnerability has been resolved:

wifi: mac80211: free AP_VLAN bc_buf SKBs outside IRQ lock

ieee80211_do_stop() removes AP_VLAN packets from the parent AP ps->bc_buf while holding ps->bc_buf.lock with IRQs disabled. It then calls ieee80211_free_txskb() before dropping the lock.

ieee80211_free_txskb() is not just a passive SKB release. For SKBs with TX status state it can report a dropped frame through cfg80211/nl80211, and that path can reach netlink tap transmit. This is the same reason the pending queue cleanup in ieee80211_do_stop() already unlinks SKBs under the queue lock and frees them after IRQ state is restored.

The buggy scenario involves two paths, with each column showing the order within that path:

AP_VLAN management TX: AP_VLAN stop:

  1. attach ACK-status state 1. clear the running state
  2. queue a multicast SKB on 2. take ps->bc_buf.lock with IRQs

parent ps->bc_buf disabled

  1. unlink the AP_VLAN SKB
  2. call ieee80211_free_txskb()

Unlink matching AP_VLAN SKBs from ps->bc_buf under the existing lock, but move them to a local free queue. Drop the lock and restore IRQ state before calling ieee80211_free_txskb().

WARNING: kernel/softirq.c:430 at __local_bh_enable_ip

Share

EUVD-2026-55591 vulnerability details – vuln.today

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy