CVE-2026-68402: Patch Linux Wi-Fi Parser Overread

The National Vulnerability Database published the record on August 10, 2026, using kernel.org as the source. The underlying wireless fix had already entered the upstream networking tree in the July 9 wireless pull request, where maintainer Johannes Berg described a group of robustness fixes that included small out-of-bounds reads. No independent security outlet appears to have published additional exploitation evidence or a proof of concept as of August 11.

The important practical point is that this is a radio-proximity attack surface: an attacker needs to operate or impersonate an access point within Wi-Fi range and deliver crafted management frames to a device that reaches the vulnerable parser. It is not a vulnerability in Windows Wi-Fi itself, and the published record does not establish code execution, data disclosure, or active exploitation.

The missing length check is one byte, but it is in kernel memory​

The vulnerable function,

, checks whether an 802.11 information element should be inherited while Linux parses nested Wi-Fi profile data. An extension element includes a generic element identifier and then a first data byte that identifies the extension type. The parser checked that the generic identifier represented an extension element, but it did not verify that the extension actually carried any data before reading

.

A zero-length

element therefore takes the parser one byte beyond the element boundary. Kernel AddressSanitizer, or KASAN, caught that as a slab out-of-bounds read while fuzzing

. KASAN is a debugging instrument that turns suspect memory accesses into loud failures; production kernels normally do not ship with the same detection overhead or reporting behavior.

The fix is deliberately narrow. Linux now returns early and treats a zero-length extension element as inherited, avoiding the read altogether. It mirrors handling already present for empty identifier lists, which is a useful sign that maintainers are correcting an omitted validation case rather than redesigning the Wi-Fi parser.

That narrow fix should guide the risk assessment. A one-byte out-of-bounds read in kernel code must be patched, especially where unauthenticated radio traffic is involved. But the record does not describe a write primitive, a use-after-free, privilege escalation path, memory disclosure primitive, or a working exploit. Calling it “remote code execution” would go well beyond the evidence.

Multi-Link and non-transmitted BSS parsing create the reachable path​

The bug does not fire for every malformed Wi-Fi frame. The kernel record says the affected inheritance check runs once a non-inheritance context exists. It gives two examples: parsing a per-station profile inside a Multi-Link element in a reassociation or association response, and parsing a non-transmitted BSS profile.

Those details matter. Multi-Link Operation is associated with newer Wi-Fi capability sets, while non-transmitted BSS profiles are used where an access point advertises multiple logical networks without each one transmitting a separate beacon. The vulnerable code exists in the shared

parsing layer, not in a single vendor driver, but practical reachability depends on the adapter, driver, kernel configuration, and the kind of management frame the system processes.

An attacker does not need to join the victim’s existing network to broadcast Wi-Fi management traffic. They do, however, need to be physically close enough to present a convincing rogue or impersonated access point, and they must get the target through one of the parsing paths described by kernel.org. That makes this materially different from an Internet-exposed service flaw that can be attacked from anywhere.

The CVE description also points to an underappreciated consequence for infrastructure teams: client Wi-Fi security depends on parser hardening even when users are not deliberately connecting to suspicious SSIDs. Management frames are processed before ordinary IP-layer protections matter. VPNs, DNS filtering, and endpoint firewalls do not correct a kernel parser reading beyond an unvalidated frame element.

The affected-version record is clearer than the CVSS record​

Kernel.org’s CVE data, as mirrored by NVD, marks Linux kernels from version 5.2 onward as affected unless they include a backport of the fix. It identifies these fixed upstream stable release points:

• Linux 6.6.148 contains the fix for the 6.6 long-term stable branch.
• Linux 6.12.101 contains the fix for the 6.12 long-term stable branch.
• Linux 6.18.42 contains the fix for the 6.18 stable branch.
• Linux 7.1.6 contains the fix for the 7.1 stable branch.
• Linux 7.2-rc4 contains the fix in the then-current development line.

The entry’s version data needs to be read as a patch map, not as a reason to install a particular upstream kernel manually. Enterprise distributions commonly backport security patches while retaining their own kernel version strings. A system reporting a version numerically lower than 6.6.148 may already be fixed if its vendor has incorporated the relevant stable change. Conversely, a self-built kernel based on the affected code needs the actual patch, not merely a distribution package update that has not yet absorbed it.

NVD has not assigned CVSS v2, v3, or v4 metrics. That is not a “low” score; it is no NVD assessment yet. Security teams that block action until a severity score appears should not do so here. The technical record is enough to prioritize the normal kernel update cycle for Linux systems that use Wi-Fi, particularly mobile endpoints, developer laptops, wireless test rigs, and devices expected to encounter untrusted networks.

There is also a calendar discrepancy worth noting. NVD lists the CVE as published on August 10, while the supplied public record shows a publication time of August 11, 2026 at 01:14 Pacific time. The underlying facts are not in dispute: the CVE is newly public, and the upstream fixes were available before the CVE listing appeared. The difference looks like a record-ingestion or timezone boundary issue, not a delayed fix.

Windows is not the target, but WSL and USB passthrough deserve a look​

Native Windows systems are not affected by this Linux-kernel CVE. Microsoft’s Windows wireless stack does not use Linux

, and installing a Windows cumulative update is not the remediation for CVE-2026-68402.

For ordinary WSL 2 deployments, the immediate exposure is also limited. Microsoft documents WSL 2 as a lightweight virtual machine using virtualized networking and a virtual Ethernet adapter; it ordinarily does not operate the host’s physical Wi-Fi adapter as a Linux wireless interface parsing over-the-air 802.11 management frames. Even mirrored networking shares the Windows networking environment at a higher level than direct access to the physical Wi-Fi radio’s management frames.

The exception is a development or lab configuration that gives the Linux guest direct access to a USB Wi-Fi adapter, a PCIe-passed-through wireless device, or a full Linux virtual machine with an actual Wi-Fi interface. In those cases, the Linux kernel and its wireless stack become relevant in the same way they are on a physical Linux laptop. WSL users who have attached a USB Wi-Fi device for monitor mode, packet capture, AP testing, or driver development should check their kernel level and update WSL if Microsoft has shipped an updated kernel package.

Microsoft’s WSL documentation identifies

as the basic way to view the installed WSL kernel version and

as the supported update path. That said, version inspection alone cannot prove the vulnerability is reachable; the decisive factor is whether that WSL kernel is actually handling Wi-Fi management frames from a passed-through wireless adapter.

What administrators should do now​

Linux administrators should identify endpoints that use Wi-Fi rather than treating this as a universal server emergency. A wired rack server with no wireless hardware has no realistic over-the-air route to the vulnerable parser, although consistent kernel patching remains good practice.

For exposed systems, the operational response is straightforward:

• Update to the vendor’s kernel package containing the CVE-2026-68402 backport, then reboot into that kernel.
• Confirm the running kernel after reboot with uname -r, but verify the distribution security advisory or package changelog when the version string does not match upstream stable numbering.
• Update custom kernels by incorporating the relevant cfg80211 fix rather than assuming an unrelated wireless-driver update addresses it.
• Give priority to roaming laptops, field devices, Wi-Fi test systems, and endpoints that join untrusted, public, conference, hotel, or customer networks.
• Keep a temporary restriction on unmanaged Wi-Fi association only where patch deployment is delayed and the device handles sensitive workloads; this is a compensating control, not a substitute for the fix.

The main lesson from CVE-2026-68402 is mundane but important: malformed Wi-Fi metadata must be validated before the kernel interprets it. Upstream Linux has supplied that validation, and stable branches have the backport points. The remaining work belongs to distribution maintainers and administrators—getting the corrected parser onto systems that actually receive untrusted Wi-Fi frames.