CVE-2026-68412 Linux Wi-Fi Leak Has No Fixed Kernel Yet

The entry was published on August 11, 2026, but the National Vulnerability Database record was not usable when checked shortly after publication: NVD returned a Cloudflare-backed HTTP 502 error rather than the CVE’s description, severity, affected-product list, or remediation data. That outage leaves administrators without the normal NVD fields they would use to automate exposure matching. The upstream patch and Linux wireless mailing-list record, however, make the underlying defect clear.

Christophe Jaillet’s proposed Linux kernel patch changes two lines of behavior in

: instead of returning directly when

exceeds

, the function records

and jumps to its established cleanup label. That path calls

, releasing the scan-request allocation before the function exits.

The vulnerable path is a legacy compatibility interface​

sits inside the Linux kernel’s cfg80211 Wi-Fi configuration subsystem. Modern Linux wireless management is built around cfg80211 and its nl80211 userspace interface, while Wireless Extensions—commonly associated with tools such as

and

—survives as compatibility code.

Linux Wireless documentation describes Wireless Extensions as maintenance-only and encourages distributions that no longer require the interface to remove

. But “legacy” does not mean unreachable. cfg80211 can provide WEXT support automatically for compatible drivers when that configuration option is enabled, which means a current kernel can retain this old ioctl-driven API even where applications have largely moved to nl80211.

The bad branch is narrow. It requires a caller to issue a WEXT scan request marked

, then supply an SSID length greater than the protocol maximum of 32 bytes. The kernel correctly rejects the request with

; the flaw is that it did so after allocating

, the object that holds channel and SSID scan information, and before reaching its cleanup code.

That distinction sets the proper severity frame. The evidence published with the patch supports a kernel memory leak on a malformed local scan request. It does not, by itself, establish a remote Wi-Fi attack, an out-of-bounds write, privilege escalation, information disclosure, or arbitrary code execution.

The patch fixes cleanup, not input validation​

The proposed change does not relax the 32-byte SSID limit or alter how a valid network-name scan works. It retains the rejection, changes the direct

to

, and routes execution to

, where

is already used for other failed scan setups.

That makes this a conventional error-path defect: validation catches invalid input, but resource ownership is mishandled on the way out. The allocation can include a per-channel pointer array, so the amount leaked per request depends on the number of channels the kernel assembled for that Wi-Fi device. The patch itself does not quantify a leak rate, a reproducible exhaustion threshold, or affected driver list.

The original patch was explicitly marked “compile tested only.” That is not unusual for a small error-path correction, but it is an important limitation in a newly assigned CVE. There is no published test result in the submitted patch showing repeated malformed scan requests, memory growth, a failure threshold, or behavior across common Wi-Fi drivers and distribution kernels.

The patch identifies Linux commit

, “cfg80211/nl80211: scanning (and mac80211 update to use it),” as the introducing change. That points to a long-lived code path rather than a regression in a recent Wi-Fi driver release. It also means version-based triage cannot safely begin with “systems running the newest kernel only.”

The public record is missing the data patch teams need​

As of the August 11 publication, the accessible record does not provide a CVSS score, CWE classification, affected kernel-version range, fixed upstream commit ID, or distributor status. The NVD’s 502 response is part of the problem, but it is not the only gap: the public patch thread shows a submitted patch, not a documented stable-tree backport plan or a list of releases containing the fix.

That has a practical consequence for enterprise Linux teams. A package scanner may recognize CVE-2026-68412 before vendors have attached it to RHEL, Ubuntu, Debian, SUSE, Oracle Linux, Android common-kernel, or appliance-kernel advisories. Until a distribution identifies its fixed package build, the only reliable technical check is whether the deployed kernel contains the cleanup change or an equivalent correction.

Administrators should also avoid treating the CVE description as a blanket finding against every Linux device. A kernel must have the cfg80211 WEXT compatibility code enabled, a Wi-Fi configuration able to reach the scan handler, and a local caller capable of exercising that interface. The public material does not yet document the exact privilege requirements for triggering the request on modern distributions, and no vendor advisory currently establishes broad in-the-wild exploitation.

For systems where WEXT is deliberately disabled, this specific handler is not compiled into the kernel. For systems where it remains enabled but Wi-Fi hardware is absent or unavailable to the guest, container, or process in question, exposure may be materially lower. Those are configuration facts to verify locally, not assumptions a CVE identifier can settle.

Do not confuse this CVE with a separate race allegation​

The mailing-list discussion contains a second, more serious-sounding claim that should be kept separate from CVE-2026-68412. In a reply to Jaillet’s patch, Xiao Wu reported independently reproducing a race between the WEXT scan path and

using the

test driver, with a KASAN-detected use-after-free following a synchronized two-thread test.

Wu explicitly said that race was pre-existing and was not introduced or fixed by Jaillet’s cleanup patch. No maintainer response in the visible thread assigns that alleged race a CVE, lands a fix, or independently validates the supplied proof of concept. It should therefore not be folded into incident response for CVE-2026-68412, whose patch is limited to freeing

on the oversized-SSID error path.

This is more than a labeling nicety. Calling the memory leak a use-after-free would exaggerate the demonstrated impact; calling the reported race fixed because the leak patch exists would create a false sense of closure. They are different defects, triggered through different control flows, with different security consequences.

What Windows and WSL administrators should do​

Windows itself is not affected by CVE-2026-68412 as a Windows kernel vulnerability. The relevant Windows-adjacent case is WSL 2, custom Linux kernels booted by WSL, Linux virtual machines hosted on Hyper-V, and dual-boot or managed Linux endpoints in a Windows fleet.

Microsoft documents that WSL 2 uses a Microsoft-built Linux kernel and that WSL servicing can be updated independently through

. Microsoft also documents WSL 2’s default NAT-based virtual Ethernet networking, which normally means a WSL guest is not directly operating the host’s physical Wi-Fi adapter through the Linux WEXT scan interface. That architecture reduces the likelihood that an ordinary WSL install presents the exact Wi-Fi scan path at issue, but it does not answer the question for custom WSL kernels, specialized networking configurations, or Linux VMs with passed-through wireless hardware.

For now, the appropriate response is measured:

• Update WSL with wsl --update and check wsl --version or uname -r, but do not assume an update contains this CVE until Microsoft publishes a kernel build containing the correction.
• Update distribution kernels through the normal vendor channel as soon as an advisory maps CVE-2026-68412 to a fixed package version.
• Audit kernels that enable CONFIG_CFG80211_WEXT, particularly appliances, embedded Linux builds, and older enterprise images carrying compatibility configurations.
• Do not disable modern Wi-Fi management wholesale; if an environment has no WEXT-dependent software, removing the legacy compatibility option at kernel-build time is the more targeted reduction.

The key unresolved item is not whether the bug exists—the patch shows the leaked allocation plainly—but which released kernels contain the fix. Until upstream and distribution records publish that mapping, CVE-2026-68412 is a real but narrowly evidenced availability flaw with incomplete remediation metadata, not a reason to declare every Windows-connected Linux workload remotely compromiseable.