CVE-2026-68351 Linux Wi-Fi OOB Write Has No Fixed Release

The immediate problem is that the public record is thinner than the CVE title suggests. The NVD page for CVE-2026-68351 was unavailable with a 502 Bad Gateway error when this item was published on August 11, 2026, and no usable NVD severity, CVSS vector, affected-version range, or fixed-version list was available from that record. The underlying Linux wireless mailing-list patch provides the technical detail, but it also exposes a material wording error in the CVE description: this is chiefly an out-of-bounds write into the destination buffer, not an out-of-bounds read.

Tristan Madani’s April 21 patch series, posted to the Linux wireless mailing list, identifies the vulnerable function as

in

. The driver detects a mismatch between the response size it expected and the size reported by firmware, logs the fault, and requests a device restart. But it then continues into a

using the firmware-controlled

value rather than the caller-provided buffer length held in

.

That continuation is the bug. A device response that claims more payload bytes than expected can cause the kernel to write beyond

, which the patch discussion says may be an on-stack command-response buffer. In other words, a malformed response is recognized as invalid, but the driver still processes it using the unsafe length.

The CVE title understates what the code does​

The submitted label for CVE-2026-68351 says “bound memcpy length in cmd callback to prevent OOB read.” The proposed fix does bound the copy:

memcpy(ar->readbuf, buffer + 4,
       min_t(u32, len - 4, ar->readlen));

But

is the destination. Before the change, the length could exceed

, so the dangerous operation is a write beyond the end of the destination buffer. The Linux code listing independently shows that the driver copies

bytes into

immediately after detecting a length mismatch.

A separate April 24 patch from Deepanshu Kartikey describes the result much more accurately: a malicious or fuzzing USB device can trigger a stack out-of-bounds write, with Kernel AddressSanitizer reporting it in

. Another patch, posted in June by HE WEI, reaches the same conclusion and recommends returning immediately after the invalid-response restart call.

That is more than a semantic correction. Vulnerability scanners, security teams, and downstream distributors use the vulnerability type to assess likely impact and prioritization. Calling this an out-of-bounds read can imply information disclosure from memory; writing past an on-stack buffer carries a different and potentially more serious class of kernel-memory-corruption risk. The available record does not establish reliable exploitability, privilege escalation, or remote attackability, so those outcomes should not be assumed. It does establish a device-controlled length reaching an unchecked kernel copy.

Firmware is the trust boundary​

drives Atheros AR9170-based 802.11n USB hardware. Linux Wireless documentation describes it as a USB driver paired with GPLv2 firmware for those older Atheros devices. The relevant input arrives over that device-and-firmware interface, rather than from an ordinary network packet handled by a modern PCIe Wi‑Fi adapter.

The practical attack precondition is therefore important. An attacker needs control of, or a path to make malicious responses through, the affected AR9170 device or its firmware interface. That can include malicious, counterfeit, compromised, malfunctioning, or fuzzed USB hardware. It is not a claim that any nearby Wi‑Fi access point can exploit every machine with a

adapter.

Still, “physical or device-level access required” is not the same as harmless. USB device attacks are relevant in lab environments, kiosk deployments, shared equipment pools, forensic workstations, embedded Linux appliances, and systems that accept untrusted peripherals. The patch series itself is framed as firmware trust boundary hardening, which captures the underlying failure: the driver treated a firmware-provided response length as actionable even after it had identified the response as malformed.

The original flaw dates back to the driver’s old receive/transmit and USB-backend work, identified in the patches as commit

. That means installations carrying the legacy driver may have inherited the behavior for many years, although the current public CVE record has not published a verified kernel-version range.

The proposed fix is not the only fix under discussion​

Madani’s CVE-linked patch chooses to cap the copy at the allocated response length and then complete the command anyway. Its rationale is operational: preserving completion avoids repeated restarts caused by queued garbage after a bad response. It is a narrow memory-safety fix, replacing an unbounded copy with one that cannot overrun the expected destination size.

Later reports raised a second issue: the code’s existing comment says an invalid response should not complete, allowing the command to time out and leaving a diagnostic trail. Yet the original function did complete it. Kartikey’s April 24 patch adds an explicit

after

and retains the bounded copy as defense in depth. HE WEI’s June patch takes the more direct path: return after scheduling the restart, so the malformed response is neither copied nor used to complete the pending command.

These patches point to an unresolved implementation detail that matters to maintainers. Bounding

fixes the demonstrated overwrite, but returning on a malformed command response better matches the function’s stated error-handling intent. A distribution backporting only the minimum CVE patch should verify which remediation its vendor adopted rather than assuming every patch with a similar title has identical behavior.

The broader three-patch April series also included a transmit-status off-by-two out-of-bounds read and an RX-stream failover buffer overflow. Those are separate code paths and should not be folded into CVE-2026-68351 merely because they were submitted together. The CVE in question is specifically the command-callback copy-length issue.

Windows and WSL 2 exposure is limited but real in one configuration​

Ordinary Windows 10 and Windows 11 installations do not load Linux’s

module for their native wireless networking, so applying Windows Update will not address — or be required for — this particular driver flaw. The affected code exists in the Linux kernel.

The Windows-adjacent case is WSL 2. Microsoft’s WSL documentation supports attaching USB devices to a WSL 2 Linux distribution using

and USB/IP. If an AR9170 USB Wi‑Fi adapter is deliberately shared with WSL, the distribution uses a kernel that includes and loads

, and that Linux environment becomes relevant to CVE-2026-68351.

That configuration requires deliberate setup; it is not how WSL normally accesses the host’s built-in Wi‑Fi adapter. But it deserves attention from developers, security researchers, and IT teams that use USB Wi‑Fi dongles for packet capture, wireless testing, device labs, or custom embedded workflows under WSL.

Administrators can quickly establish whether the driver is in play on Linux with:

They can also inspect connected USB hardware with:

A positive

module result is the meaningful trigger for follow-up. A system using Intel

, Realtek

, MediaTek

, or another unrelated wireless driver is outside this CVE’s driver scope.

No fixed release has been established in the public CVE record​

As of August 11, 2026, the available materials show proposed and revised Linux wireless patches, KASAN-backed reports of the overflow condition, and a newly published CVE identifier. They do not show an NVD enrichment record, a published severity score, a confirmed upstream mainline commit, or a distributor advisory listing patched package builds for CVE-2026-68351.

That absence changes the immediate response. Organizations with AR9170 hardware should not wait for a CVSS score to identify affected systems: inventory

, restrict untrusted USB Wi‑Fi adapters, and monitor their Linux distribution’s kernel advisory stream for the eventual backport. If the adapter is not required, unloading or blacklisting the module is a practical temporary reduction in exposure.

For everyone else, this is a reminder to read CVE labels against the patch. CVE-2026-68351 is a legacy Linux USB Wi‑Fi driver memory-corruption issue whose public title says “read,” while the code path and sanitizer report describe a write past a response buffer. The fix to watch for is one that either safely bounds the copy or, preferably, rejects the malformed response before it can be copied or completed.