← Back to CVE intelligence
CVE intelligence

CVE-2026-68405

Vulnerability intelligence

Published Aug 10, 2026Sources checked Oct 28, 2026
N/ACVSS not listedScore unavailable
What this means

Review the available evidence

CVE-2026-68405. It is not in the current CISA KEV record we collected. That does not prove exploitation has not occurred.

What to do next

Remediation and response

Microsoft Security Response Center guidance

Vendor revision: Aug 14, 2026

CBL-Mariner Releases

Vendor-listed releases

  • 6.6.150.1-1
CISA KEVNot listedBased on the latest collected catalog
EPSS0.2%Estimated 30-day exploitation probability
Ransomware useNot markedCISA KEV ransomware field
Threat actors0Source-linked actor relationships
Overview

What is CVE-2026-68405?

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 3. unlink the AP_VLAN SKB 4. 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

Source: NVD