CVE-2026-68409: Patch Linux Wi-Fi 7 mac80211 UAF

The newly published NVD entry records fixed upstream releases as Linux 6.18.42, Linux 7.1.6, and Linux 7.2-rc4. It currently has no CVSS score or CWE classification from NIST. The vulnerability report was first laid out in a June Linux kernel mailing-list post by Maoyi Xie, and the upstream patch subsequently landed in the stable kernel trees named by the CVE record.

There is one timestamp wrinkle worth separating from the technical issue. The CVE feed supplied with this record carries a publication time of August 11, 2026, at 1:12 a.m. Pacific time, while NVD’s quick-information field lists August 10, 2026 as its publication date. That is a publication-record timing difference, not evidence of a changed fix or a revised severity assessment.

The bug is an RCU lifetime mistake in mac80211​

The vulnerable code sits in

, within the station-link teardown path used by Multi-Link Operation, or MLO. MLO is the Wi‑Fi 7 mechanism that allows one logical connection to use multiple radio links. A client can, for example, operate across more than one band and later remove a link without necessarily tearing down the entire station.

The affected path removes an MLO link and immediately releases its per-CPU receive-statistics allocation,

. At the same time, it postpones release of the surrounding link container through

. That split lifetime is the defect: the larger object remains valid to RCU readers, but one pointer inside it can already reference reclaimed memory.

Linux’s RCU, short for Read-Copy-Update, permits read-side code to retain a pointer inside an

section while an updater removes the object from live lookup structures. The updater must wait for those readers to drain before freeing anything those readers may still dereference. Kernel documentation describes that as the core RCU guarantee: data accessed under the read-side lock must remain unreclaimed for the full critical section.

Here, the receive fast path can obtain the MLO link pointer under RCU and then write receive statistics through

. If link removal happens in the narrow interval after that pointer was resolved but before the stats write completes, the code can write into memory that has already been freed. The container’s RCU-delayed free does not save the separately freed per-CPU block.

That is why the patch’s design is more important than the small diff implied by its title. Rather than adding a broad synchronization point to every link-removal operation, it moves link cleanup and its statistics allocation into one RCU callback. The stats block now survives for exactly as long as any reader may retain the link pointer.

The trigger is narrow, but it is a real memory-safety defect​

The upstream report is unusually clear about the preconditions. This is not a general Wi-Fi disconnect bug affecting every

client. The race requires the MLO link-removal path, receive-side RSS statistics allocation, and timing that overlaps a concurrent receive softirq with removal of an active link.

The kernel mailing-list analysis says the over-the-air trigger is an MLO link removal delivered through a Multi-Link Reconfiguration element. It also says the race is difficult to win in practice. That should inform operational priority, but it should not be mistaken for a mitigation: a difficult race that produces a kernel use-after-free remains a kernel memory-corruption condition.

The original researcher did not present an end-to-end exploit and explicitly noted that the finding came from code inspection rather than testing on Wi‑Fi 7 hardware. They did, however, report that a reduced test which frees the stats buffer and writes through the still-live container triggered KASAN, Linux’s kernel memory error detector. That is meaningful confirmation of the lifetime error, even though it does not establish remote code execution, privilege escalation, or a practical attack chain.

The available public record therefore supports a measured conclusion: CVE-2026-68409 warrants patching on systems that use mac80211 with MLO-capable hardware, but there is no basis yet to portray it as a broad remote compromise of Linux Wi-Fi clients. NVD has not assigned a severity score, and the CVE entry does not provide exploitation evidence, an affected-driver inventory, or a vendor-specific exposure assessment.

Linux 6.0 is the introduction point, not the deployment answer​

NVD marks Linux 6.0 and later as affected until the fixed releases on the relevant maintained branches. That aligns with the upstream history: the station link-addition and removal infrastructure underlying this path was added during the Linux 6.0 development cycle in 2022.

That version number can still mislead fleet operators. The vulnerable code may have existed upstream from Linux 6.0 onward, but MLO capability depends on the actual wireless device, driver support, firmware behavior, kernel configuration, and whether the system is using the relevant mac80211 functionality. A server kernel with no Wi‑Fi hardware is not meaningfully exposed to this receive-path race merely because its version is numerically within the affected range.

Conversely, a distribution’s kernel version string does not settle the question by itself. Enterprise and long-term-support distributions routinely backport targeted fixes without adopting the upstream release number shown in a CVE database. A host identifying itself as an older kernel can be fixed; a custom kernel derived from a newer tree can remain vulnerable if it omitted the patch.

Administrators should check the distribution’s security advisory or kernel changelog for CVE-2026-68409 and confirm the running kernel after reboot. The three stable commits listed in the NVD record are the authoritative upstream patch references, but distribution package maintenance is the practical source of truth for deployed systems.

Windows and WSL 2 are mostly outside the blast radius​

Native Windows Wi-Fi uses Microsoft’s networking and wireless driver stacks, not Linux

. Installing an August Windows cumulative update will not be the remedy for CVE-2026-68409 because the vulnerable code is not part of Windows itself.

Standard WSL 2 deployments are also unlikely to enter the affected path. Microsoft documents WSL 2 as a lightweight virtual machine using a virtualized Ethernet adapter, typically under NAT and, on supported systems, optionally under mirrored networking. That design lets Linux applications use network connectivity, but it does not hand the distribution direct control of the Windows host’s internal Wi‑Fi adapter through

.

The exception is a specialized setup: a user can attach compatible USB hardware to WSL 2 through USB/IP, provide a Linux driver, and use that hardware from the guest. If that hardware is a Wi‑Fi adapter driven through mac80211 and is used for MLO, the guest kernel—not Windows’ normal wireless stack—becomes relevant. That is a niche configuration, but it means “running WSL” is not a universal exclusion.

For conventional Windows users, there is no immediate action beyond keeping WSL current as a normal maintenance practice. For dual-boot machines, Linux laptops with Wi‑Fi 7 hardware, wireless test systems, and custom Linux appliances, the correct response is to install the distribution kernel update and reboot into it.