CVE-2026-68405: Linux AP VLAN Kernel Fix Reaches Stable

The record, published by kernel.org and now listed by the National Vulnerability Database, identifies

as the affected file. It says the vulnerable code has existed since Linux 3.9 and that fixed upstream releases are Linux 6.6.148, 6.12.101, 6.18.42, 7.1.6, and the then-current 7.2-rc4 development tree. Those version numbers are useful for upstream users, but they are not a complete answer for distribution users: enterprise and long-term-support distributions commonly backport individual patches without changing their base kernel version to the corresponding upstream release.

The bug is in AP VLAN teardown, not ordinary Wi-Fi use​

mac80211 is Linux’s common wireless LAN framework, used by many Wi-Fi drivers and by software access-point deployments. CVE-2026-68405 is specifically concerned with an AP_VLAN interface: a virtual interface created under an access point, commonly in hostapd-based installations that place wireless clients into VLANs.

The affected routine,

, runs when that AP VLAN interface is shut down. It removes matching packets from the parent access point’s buffered broadcast and multicast queue,

. The queue is protected by a spinlock, and this cleanup path holds that lock with interrupts disabled.

The problem is what happens next. Rather than merely releasing memory, the routine called for each removed socket buffer —

— can process transmit-status information. When a frame was waiting for acknowledgement status, freeing it can report a dropped packet upward through cfg80211 and nl80211, Linux’s wireless configuration and notification layers. That notification path can reach netlink packet-tap transmission, which is work the kernel should not perform while it remains inside this IRQ-disabled locked section.

Kernel developers recorded the resulting warning as

. In practical terms, the code can reach a path that re-enables bottom-half processing while the calling context is still wrong for it. The CVE does not claim memory corruption, privilege escalation, or a network-reachable attack primitive. It documents a locking-context failure that can surface as a WARN condition during a narrow race.

That scope substantially narrows the affected population. A laptop merely connecting to a home or office Wi-Fi network is not exercising this AP VLAN teardown path. The relevant setups are machines acting as Wi-Fi access points with AP VLAN interfaces, particularly where multicast or broadcast buffering for power-saving clients and management-frame transmit status are active while an AP VLAN interface is being removed.

The fix deliberately separates queue removal from packet disposal​

The patch is small but its design is telling. It does not loosen or remove the protection around

; the queue still has to be modified under its existing lock. Instead, the fix changes the lifetime sequence for the affected packets.

The repaired logic does three things:

1. It finds and unlinks packets belonging to the AP VLAN while holding ps->bc_buf.lock.
2. It puts those removed packets on a temporary local free queue rather than freeing them immediately.
3. It drops the spinlock and restores interrupt state before calling ieee80211_free_txskb() for each deferred packet.

That mirrors an existing pattern in the same teardown routine for pending transmit queues. The kernel’s own CVE description explicitly notes that another cleanup path already unlinked packets while locked and deferred actual freeing until interrupts had been restored. This is less a newly invented mitigation than a correction bringing AP VLAN buffered-frame cleanup into line with established local practice.

The underlying consequence matters for anyone auditing a custom or downstream kernel patch. A change that simply wraps

differently, or that moves the entire search-and-unlink operation outside the lock, would not be equivalent. The lock protects the parent AP’s broadcast-buffer queue from concurrent modification; the patch preserves that protection and only postpones the operation that can escape into higher-level networking work.

The code path also explains why treating every “free an SKB” call as harmless can be a mistake. In kernel networking, a socket buffer may carry state beyond payload memory. Here, transmit-status handling turns disposal into an externally visible dropped-frame notification. The defect is not a basic double-free or use-after-free condition; it is that cleanup invoked behavior with broader networking side effects from an IRQ-disabled critical section.

Fixed upstream versions need translation before they become deployment advice​

The kernel.org CVE record marks upstream versions before 6.6.148 in the 6.6 series, before 6.12.101 in the 6.12 series, before 6.18.42 in the 6.18 series, and before 7.1.6 in the 7.1 series as affected. The mainline fix is recorded as present in 7.2-rc4. Five stable backport commits are listed in the CVE record, one for each supported upstream branch.

For self-built kernels or appliance vendors that track upstream stable releases closely, the operational response is straightforward: move to one of those fixed releases or apply the corresponding stable backport. A system on 6.6.147, for example, should be considered exposed to this bug even though 6.6 is an older long-term-supported branch; the relevant fixed point is 6.6.148.

Distribution-maintained kernels require a different check. Red Hat, SUSE, Canonical, Debian, and other vendors may carry the fix in a package whose visible version looks older than the upstream fixed release, while a custom kernel built from an old source snapshot may remain vulnerable despite bearing a familiar distribution-style release name. The defensible process is to inspect the distribution’s security advisory, changelog, source package, or patch list for CVE-2026-68405 or the mac80211 AP VLAN free-queue change.

Do not infer status solely from

. The CVE data supplies upstream cutoffs, not a universal map of vendor package builds. As of August 11, 2026, the NVD has not enriched this record with CPE mappings, a CVSS score, CWE classification, or vendor advisories that would make product-level fleet matching automatic.

Windows systems are generally outside the direct exposure path​

For Windows users, this is not a Windows Wi-Fi driver vulnerability. The affected code lives in the Linux kernel’s mac80211 access-point stack, and it requires a Linux instance to operate a relevant Wi-Fi AP VLAN configuration.

WSL 2 also should not be treated as equivalent to a Linux laptop directly managing its host’s Wi-Fi radio. Microsoft’s WSL documentation describes WSL 2 as a lightweight virtual machine using a virtualized Ethernet adapter, with NAT networking by default. Even Windows 11’s mirrored networking mode changes the connectivity model presented to Linux; it does not document handing the physical Windows Wi-Fi adapter and its native mac80211 control path to the WSL kernel.

That architecture means an ordinary Windows 11 PC running Ubuntu, Debian, or another WSL distribution is generally not a practical target for this particular bug merely because the Windows host uses Wi-Fi. The more relevant Windows-adjacent cases are Linux virtual machines with direct wireless-device passthrough, dedicated access-point appliances managed from Windows, and test rigs using a Linux host kernel with a physical Wi-Fi adapter configured for hostapd and dynamic AP VLANs.

The risk is higher for infrastructure than for endpoints. A managed wireless gateway or lab access point may repeatedly create and stop AP VLAN interfaces during configuration changes, client segmentation events, service restarts, or automated provisioning. If the trigger aligns with buffered multicast traffic and transmit-status processing, administrators could see a kernel warning in the log during interface teardown rather than an immediately obvious Wi-Fi failure.

What administrators should verify now​

The immediate maintenance task is to identify Linux systems that both run a vulnerable kernel and use mac80211-based access-point VLAN functionality. The CVE itself offers no evidence of exploitation in the wild, and no severity score has been assigned. Still, kernel warnings in networking control paths deserve attention, especially on appliances that need predictable wireless service during interface changes.

Administrators should prioritize systems that run hostapd with per-client or dynamic VLAN assignment, AP VLAN interfaces, or scripts that frequently start and stop wireless virtual interfaces. Review

and journal logs for the softirq warning named in the CVE description, then confirm whether the installed vendor kernel includes the upstream fix.

For ordinary client systems and standard WSL 2 installations, this CVE does not call for a special Windows-side mitigation. For Linux access-point hosts, the concrete next step is to update to a vendor kernel that documents the backport or to an upstream stable release at or beyond the applicable fixed version. The key practical distinction is simple: patch the Linux machine that owns the Wi-Fi AP VLAN workload, not the Windows machine that merely happens to be nearby.