link-1/txpower can dereference the dangling pointer and panic the machine.The Linux kernel CVE record says the bug was introduced in Linux 6.4 and is fixed in the current stable streams at 6.6.148, 6.12.101, 6.18.42, and 7.1.6, as well as Linux 7.2-rc5. The upstream Linux 7.2-rc5 announcement also includes the patch under Xiang Mei’s name, independently confirming that the correction landed in the release-candidate tree rather than existing only as a CVE database entry.
For administrators, the practical action is straightforward: update to a vendor kernel containing the backport. Do not rely on the fact that a distribution kernel’s version number looks older than 6.6.148, however. Enterprise and distribution vendors commonly backport security fixes without adopting upstream’s complete version number, so the package changelog, vendor advisory, or source-package patch list is the record that decides whether a deployed kernel is protected.
The bug lives in a failed MLO link update
mac80211 is Linux’s in-kernel framework for a large class of SoftMAC Wi‑Fi drivers. It handles much of the 802.11 management work in software, while the hardware-specific driver carries out device and firmware operations. CVE-2026-64574 sits in
net/mac80211/link.c, in code responsible for changing the links associated with a virtual interface.
The vulnerable path is unusually narrow. When mac80211 adds new links during a virtual-interface update, it allocates a container for each new link, initializes it, and creates corresponding per-link debugfs entries. It then asks the hardware driver to apply the new link configuration through
drv_change_vif_links().
If that driver callback fails, the old configuration pointers are restored and the newly allocated containers are freed. The missing step was teardown: mac80211 did not remove the new links’ debugfs entries or stop the newly initialized links before freeing their storage. The files remained visible, but their private data pointed into freed kernel memory.
That is why this is a use-after-free rather than a simple cleanup leak. The stale file is a live handle into invalid state. The CVE description identifies
ieee80211_if_read_link()as the later read path that dereferences it, and documents a KASAN report followed by a general-protection fault and kernel panic.
The patch makes the failed add-link path use the teardown logic that already existed for link removal. That logic removes link keys and debugfs entries and invokes the link-stop routine before freeing the link containers. It is a focused fix: no change to ordinary Wi‑Fi traffic, but a correction to the failure cleanup sequence when a driver rejects a new MLO link configuration.
The earlier cleanup fix did not cover added links
The advisory’s most useful detail is that this was not an entirely unexamined error path. A prior upstream commit,
be1ba9ed221f, described as “wifi: mac80211: avoid weird state in error path,” hardened the counterpart case where links were being removed. It did not handle the case where new links had been created and then the driver’s configuration update failed.
That history matters because it explains both the bug and its scope. The exposed state does not arise from every Wi‑Fi disconnect, every scan failure, or every driver reset. It requires mac80211 to be adding MLO links, the driver operation applying that addition to fail at runtime, and the stale debugfs node subsequently to be read.
The Linux CVE record names possible failure categories inside the MLO driver path: internal allocation failure, queue failure, or a failed firmware command. Those are not remote attack packets in themselves. They are error conditions after mac80211 has begun preparing additional Wi‑Fi links.
The result is a vulnerability that security scanners may label broadly as a Linux kernel issue while the affected execution path is much more specific. A system needs a kernel from the vulnerable range, mac80211 support, an MLO-capable driver using this update path, and enabled debugfs support. It must also encounter the driver failure condition that leaves the dead debugfs file behind.
debugfs is the gate most summaries leave out
The dangling interface is in debugfs, Linux’s developer-oriented virtual filesystem usually mounted at
/sys/kernel/debug. Kernel documentation is explicit that debugfs is not a stable user-space ABI and that entries created there do not clean themselves up automatically. It also says the debugfs root is accessible only to root by default, although administrators can alter ownership and mode when mounting it.
That default substantially changes the real-world reading of this CVE. The kernel.org CNA assigned CVSS 3.1 vector
AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H, a 7.8 High rating. NVD has published the record but, as of August 9, has not issued its own CVSS assessment. Readers seeing a High score should recognize that it is the Linux kernel CNA’s score, not an independent NVD severity judgment.
More importantly, the score does not eliminate the debugfs condition. On a conventional desktop or server where debugfs is unmounted, disabled in the kernel configuration, or left with root-only access, the described stale file cannot be opened through the path documented in the advisory. Where debugfs is deliberately exposed to diagnostics tooling, containers, test users, or low-privilege service accounts, the permissions and mount configuration deserve review.
The CVE record’s included task name,
exploit/145, should not be mistaken for evidence of a released exploit. It is part of the KASAN crash trace supplied with the bug report. Neither the NVD entry nor the Linux 7.2-rc5 announcement identifies public exploitation in the wild or names an affected commercial Wi‑Fi driver. No other public reporting located for this newly published CVE provides those missing details.
That does not make the crash benign. Use-after-free conditions are security-relevant precisely because their effects can depend on heap layout and execution context. But the public record presently supports a documented local crash scenario; it does not establish a remotely reachable Wi‑Fi compromise or a confirmed privilege-escalation chain.
The affected version range has a clear floor and five fix lines
The CVE metadata names Linux 6.4 as the first affected upstream release. Linux versions before 6.4 are listed as unaffected. The supplied fix points cover four maintained stable branches plus the development line:
- Linux 6.6.148 contains the stable-tree correction for the 6.6 series.
- Linux 6.12.101 contains the correction for the 6.12 series.
- Linux 6.18.42 contains the correction for the 6.18 series.
- Linux 7.1.6 contains the correction for the 7.1 series.
- Linux 7.2-rc5 contains the upstream development-tree fix.
Those numbers are more useful for self-built kernels and distributions that track upstream closely than for enterprise fleets. Red Hat Enterprise Linux, Ubuntu LTS, SUSE Linux Enterprise, Android-derived kernels, appliance kernels, and cloud-provider images may use a substantially different release string while carrying the same patch. Conversely, a later-looking downstream release should not be presumed fixed until its vendor confirms the backport.
Administrators should check the running kernel with their normal inventory tooling, then consult their distribution’s security tracker or package changelog for CVE-2026-64574. Systems compiling custom kernels should either move to one of the corrected releases or apply the upstream patch and rebuild. Rebooting is necessary after an installed kernel update; the Wi‑Fi stack running in memory is not repaired by updating files on disk.
What Windows administrators should and should not chase
This is a Linux kernel vulnerability in mac80211. It does not describe a flaw in the Windows Wi‑Fi stack, a Windows 11 cumulative update issue, or a Microsoft Wi‑Fi driver advisory. Windows endpoints do not need a Windows patch for CVE-2026-64574.
The relevance for Windows-focused IT teams is in mixed estates: Linux laptops, Wi‑Fi test hosts, network appliances, build agents, developer workstations, and virtualized Linux systems administered from Windows. Those systems should be evaluated as Linux hosts, particularly where engineers enable debugfs for driver debugging or where new MLO-capable hardware is being validated.
WSL environments should not be treated as automatically exposed merely because they run a Linux kernel. The published advisory concerns mac80211 link management and per-link debugfs files on the Linux side; it does not identify WSL, Hyper-V networking, or Windows-hosted virtual Wi‑Fi as affected configurations. Any WSL-specific exposure claim would require evidence the current advisory does not provide.
The concrete consequence is narrower than the CVSS headline but urgent for the systems that match it: an MLO driver error can turn a later diagnostic read into a kernel crash. Patch the kernel branch your distribution has actually shipped, verify the rebooted version, and keep debugfs restricted to the administrators and tools that genuinely need it.
References
- Primary source: NVD / Linux Kernel
Published: August 9, 2026 at 8:42 AM UTC
Loading…
nvd.nist.gov - Security advisory: MSRC
Published: August 9, 2026 at 8:42 AM UTC
Original feed URL
Loading…
msrc.microsoft.com - Related coverage: nvd.nist.gov
Loading…
nvd.nist.gov - Related coverage: android.googlesource.com
Loading…
android.googlesource.com - Related coverage: docs.kernel.org
Loading…
docs.kernel.org - Related coverage: wireless.docs.kernel.org
Loading…
wireless.docs.kernel.org - Related coverage: wireless.docs.kernel.org
- Related coverage: blogs.oracle.com
Loading…
blogs.oracle.com - Related coverage: docs.oracle.com
Loading…
docs.oracle.com