CVE-2026-68352 Fixed in Linux 6.6.148 and Stable Kernels

For Windows users, this is not a Windows Wi-Fi vulnerability. ath6kl is a Linux driver for older Qualcomm Atheros mobile wireless hardware, and ordinary Windows networking does not load it. The practical concern is for administrators running Linux directly on affected embedded, industrial, or legacy Atheros-equipped devices—and, more narrowly, for custom WSL 2 or virtual-machine deployments that expose compatible hardware and deliberately enable this driver.

The awkward part of this disclosure is that the National Vulnerability Database page was unavailable on August 11, returning a Cloudflare 502 error rather than the record details. That outage does not leave the advisory unverified: the Linux CNA’s published CVE record contains the affected source file, upstream and stable fix commits, and fixed kernel versions. It also exposes a timing discrepancy worth noting. NVD showed the item as published on August 11, while the Linux CNA record says it was published at 12:03 UTC on August 10, 2026. Those timestamps reflect different publication systems, not two different vulnerabilities.

The bug is in how ath6kl trusts its own firmware​

The vulnerable code sits in

, in the

routine. When the Wi-Fi firmware tells the host driver that a connection has completed, the event contains three firmware-supplied lengths:

,

, and

.

Those fields describe three blocks of 802.11 Information Elements, or IEs, carried after the fixed portion of the connection event. The driver used those lengths to locate and parse the data without first proving that the combined size actually fit inside the received WMI event buffer.

As Tristan Madani’s April 21 kernel patch explains, the three one-byte values can total as much as 765 bytes. If the firmware event is shorter than that declared total, the driver can walk past the buffer during IE parsing. The kernel’s CVE record specifically identifies two consequences: an out-of-bounds read and corruption of

, a driver state flag associated with Wi-Fi Multimedia support.

The fix is small but important. Before the driver processes the event, it now checks whether the full event header plus all three declared IE lengths exceeds the actual received buffer length. If it does, ath6kl logs the invalid lengths and returns

rather than parsing data that is not there.

This is a textbook firmware trust boundary failure. The host kernel treated metadata supplied by a peripheral’s firmware as internally reliable even though that firmware is outside the kernel’s memory-safety guarantees. The patch series was explicitly submitted under the heading “firmware trust boundary hardening.”

The exposure is narrower than a generic Wi-Fi attack​

CVE-2026-68352 should not be read as “any malicious Wi-Fi access point can immediately read arbitrary Linux kernel memory.” The flawed values come from the device firmware’s connect-event message to the host driver, rather than from a normal userspace Wi-Fi API. The supplied patch and the Linux CNA record do not describe a public proof of concept, active exploitation, or a direct over-the-air attack chain.

That does not make the bug harmless. A malformed firmware event can arise from faulty firmware, firmware that has itself been compromised, device emulation, or a hardware/virtualization arrangement that can feed crafted events into the driver. An attacker who can influence that boundary may be able to induce a kernel out-of-bounds read during connection handling, with behavior depending on the adjacent memory and compiler/runtime conditions.

The state-corruption detail is also more useful than the usual vague “memory corruption” label. The disclosed code path can overwrite the driver’s WMM-enabled state based on bytes beyond the valid event. That points first toward stability and connection-state integrity problems rather than establishing a proven privilege-escalation route. No CVSS vector or score appears in the Linux CNA record as published, and no independent exploit reporting was identified as of August 11.

Administrators should therefore prioritize this according to exposure:

• Devices that do not build or load ath6kl are not affected by this specific flaw.
• Systems using ath6kl hardware and older vendor kernels should treat the update as a kernel-security maintenance item, especially where firmware provenance is weak or hardware is physically accessible.
• Appliances and embedded products deserve extra attention because they often keep old long-term kernels and use the kinds of mobile Atheros chipsets ath6kl was designed to support.

Kernel version alone is not enough for vendor builds​

The Linux CNA marks ath6kl versions beginning with Linux 3.2 as affected until the relevant fix enters each supported branch. The listed fixed releases are:

The vulnerable driver code dates back to commit

, the original ath6kl driver cleanup that landed before the Linux 3.2 release. That gives this defect a long historical reach, but it does not mean every kernel numerically older than the fixed releases remains vulnerable. Enterprise and appliance vendors frequently backport security fixes without changing the visible upstream version in the way a simple comparison expects.

For example, a vendor kernel identified as 6.6.x might carry the correction before adopting the exact upstream 6.6.148 release number. Conversely, a downstream kernel can retain ath6kl code without incorporating the patch even when its surrounding product release is newer. The reliable test is the vendor’s security advisory, source package changelog, or confirmation that the stable backport corresponding to CVE-2026-68352 has landed.

The Linux CNA record identifies five stable-tree fix commits, one for each maintained branch. That is a useful signal that this is not merely a wireless-next cleanup awaiting general availability: the correction has been carried into the stable maintenance pipeline.

Why normal Windows installations are outside the blast radius​

Windows 10 and Windows 11 use Windows networking drivers for local Wi-Fi adapters; they do not use Linux’s

module. Installing a Windows cumulative update or updating an Atheros driver through Device Manager does not patch, or need to patch, CVE-2026-68352.

WSL 2 makes the boundary less obvious because it runs a real Linux kernel managed by Microsoft. Microsoft’s public WSL2-Linux-Kernel repository confirms that WSL 2 ships and maintains its own Linux kernel and configuration. But a stock WSL 2 instance uses virtualized networking rather than directly operating the host’s physical Wi-Fi chipset through ath6kl. Merely having Ubuntu, Debian, Kali, or another distribution installed under WSL is therefore not evidence of exposure.

The exception is a custom configuration: a WSL 2 or virtual-machine user who installs an affected kernel, enables ath6kl, provides its firmware, and passes through compatible USB or other hardware could create the necessary conditions. That is far removed from ordinary WSL usage, but it is the sort of edge case that matters in lab, driver-development, and device-validation environments.

On Linux systems where the driver may be relevant, administrators can first establish whether it exists:

If the module is present, check whether it is loaded:

Then identify the running kernel:

Those commands establish configuration and version context; they do not prove that a vendor backport is present. For managed fleets, package metadata and vendor security notices remain the correct remediation evidence.

The immediate action is a kernel update, not a Wi-Fi workaround​

The fix rejects inconsistent firmware event lengths before the host driver parses them. There is no announced configuration toggle, registry value, driver parameter, or firewall rule that reproduces that protection safely. If ath6kl is in use, the remedy is to deploy a kernel package carrying the backport or upgrade to one of the fixed upstream releases.

For everyone else—including nearly all Windows desktops and standard WSL 2 installations—CVE-2026-68352 is a Linux wireless-driver advisory to track, not an emergency Windows patch event. The important operational question is simply whether an affected Linux system loads ath6kl; if it does, kernel maintenance should move ahead of any attempt to mitigate this at the network layer.