CVE-2026-68350 Fixes Linux AR9170 Wi-Fi Driver OOB Read

The CVE was published to the NVD on August 10, 2026, using kernel.org as its source. It carries no NVD-assigned CVSS score and no published exploitation status, but that absence is an assessment gap rather than a clean bill of health: NVD has not completed enrichment, and the record does not document a tested attack scenario or affected distributions.

For Windows users, the immediate distinction is simple. Native Windows does not load Linux’s

module, so CVE-2026-68350 is not a vulnerability in Windows Wi-Fi, the Windows networking stack, or a standard WSL 2 installation. It becomes relevant on a Windows workstation when a Linux kernel is actually driving the USB adapter: a Linux virtual machine with USB passthrough, a bare-metal Linux dual-boot installation, an appliance, or a WSL 2 environment deliberately given the physical USB device through USB/IP.

The faulty comparison permits two invalid status reads​

The offending routine,

, walks the transmit-status entries returned by the adapter’s firmware. The loop count comes from

, while the size of the response supplies the real boundary: a status entry consumes two bytes, so the maximum number of valid entries is

.

Before the fix, the driver stopped only when the loop index was greater than

. That condition is late by two entries. If firmware reports an extension count larger than the response can legitimately hold, the parser accepts two indexes beyond the end of the

array before its warning condition breaks the loop.

Tristan Madani’s April 2026 patch series on the Linux wireless mailing list documented the exact one-line correction:

The code is small; the consequence is not. The old check turns a warning intended to enforce the protocol boundary into a post-boundary warning. On each invalid iteration, the driver takes a

and status-information byte from memory beyond the parsed firmware response and passes them to the transmit-status handling path.

The Linux mainline diff, mirrored by Google’s kernel source browser, confirms that this exact comparison changed in

. The mailing-list patch and the mainline code therefore agree on both the bug and the remedy; this is not an NVD description that has drifted from the upstream source.

There is an important limit to what the public record establishes. The CVE describes an out-of-bounds read, not an out-of-bounds write, use-after-free, or confirmed route to code execution. It also says the controlling value originates in firmware, but it does not show that ordinary nearby Wi-Fi traffic can make legitimate firmware emit a malformed response. Claims that this is remotely exploitable over 802.11, or that it produces kernel code execution, would run ahead of the available evidence.

This is a firmware trust-boundary bug in aging USB Wi-Fi hardware​

supports Atheros AR9170-family USB 802.11 draft-n adapters. Linux Wireless documentation identifies it as the in-kernel driver for devices using GPLv2 firmware, and its supported-device list includes hardware sold under many older brands: Netgear’s WN111 v2 and WNDA3100 v1, D-Link’s DWA-130 revision D and DWA-160 A-series, TP-Link’s TL-WN821N v2, AVM FRITZ!WLAN USB Stick N models, and various Atheros-, Zydas-, and Zyxel-branded products.

That broad product history is a reason to inventory by USB ID or loaded driver rather than a retail name. A dongle labeled “Wireless N” can be old enough to use AR9170 silicon, while a newer revision sold under the same model name can use a completely different chipset and driver.

The driver has existed since Linux 2.6.37, according to the CVE record’s affected-version data, meaning this boundary error was present for roughly 15 years before being assigned CVE-2026-68350. The original vulnerable commit is identified as

, whose subject was “carl9170: 802.11 rx/tx processing and usb backend.”

The age of the driver changes the operational risk calculation. These adapters are uncommon in current employee laptops, but they persist in labs, packet-capture kits, radio-testing setups, long-lived embedded deployments, and low-cost USB inventory kept for recovery work. Linux Wireless itself cautions that the AR9170 generation was designed during the draft-802.11n era and has known compatibility and reliability limitations. That does not prove malicious exploitation, but it does mean a device that can already be operationally temperamental should not be kept on an unpatched host merely because it still associates successfully.

The CVE is also part of a larger April hardening series for the same driver. The surrounding patches addressed a separate firmware-response copy bound and an RX-stream failover overflow. Those are distinct fixes and should not be collapsed into CVE-2026-68350, but their presence shows why the correct response is to take the maintained kernel update as a whole instead of manually transplanting one line without reviewing related driver changes.

Fixed upstream branches are known; distribution status is not​

The CVE record identifies five stable-tree fix commits and maps the correction to the following upstream kernel points:

The record’s version syntax is awkward: it labels the first fixed release in each branch as “unaffected,” then applies that status across the corresponding series. Read it as a fix floor, not as evidence that every vendor kernel sharing a lower-looking version string remains vulnerable. Enterprise distributions routinely backport individual stable fixes while retaining their own base-version naming.

That makes

a starting point, not a verdict. A distribution’s advisory, package changelog, or source package must show that its kernel includes one of the stable commits referenced by the CVE, or an equivalent backport. Conversely, a system reporting a generic version such as

should not be assumed safe until it is at least 6.6.148 upstream-equivalent or the distributor confirms the backport.

The patch’s presence in five maintained upstream lines is useful evidence that maintainers regarded it as suitable for stable backporting. What is still missing on August 11 is a public vendor-by-vendor rollout picture. The NVD entry names affected Linux source versions but does not list Red Hat, Canonical, SUSE, Debian, Android, VMware, appliance vendors, or managed-kernel offerings. No public advisory in the material reviewed ties CVE-2026-68350 to a particular distribution package.

Windows, WSL 2, and virtual machines have a narrow exposure path​

A conventional Windows PC with one of these adapters is outside the affected code path. Windows will use a Windows driver for the device; it does not load Linux’s

. Likewise, WSL 2 normally uses virtualized networking rather than controlling the host’s physical Wi-Fi USB adapter through the Linux driver. Microsoft’s WSL networking documentation describes a virtualized Ethernet adapter in the default architecture.

The exception is deliberate raw USB attachment. Microsoft documents that WSL 2 can receive a physical USB device through the

USB/IP workflow, after the Windows host shares and attaches the selected bus device to WSL. Once attached, Windows cannot use the device concurrently, and the Linux guest can interact with it using normal Linux tools. If the passed-through hardware is an AR9170 adapter and Linux binds

, the vulnerable parser is in scope.

Virtualization administrators should apply the same reasoning to Hyper-V, VMware Workstation, VirtualBox, Proxmox, and other hypervisors: the host operating system is not affected merely by having the device present, but the guest that owns the USB device and loads

is. USB redirection policies and physical-device passthrough therefore matter more than whether the person operating the machine sits at a Windows desktop.

What administrators should do now​

First, identify whether any Linux system actually loads the module. On a Linux host or guest,

is the quickest check for an active module;

,

,

, and

can help link it to a physical adapter. An inventory based on the AR9170 USB vendor and product IDs is more durable where the device may not currently be connected.

Second, install the distributor kernel update that includes the fix. For self-built kernels, use 6.6.148, 6.12.101, 6.18.42, 7.1.6, or a newer upstream-equivalent build, or confirm that the stable commit was backported. Administrators with a custom kernel that cannot yet be upgraded can apply the one-line correction, rebuild the module or kernel, and test with the actual adapter, but that should be a temporary containment measure rather than a substitute for taking the maintained update series.

Third, remove or deny passthrough of unused AR9170 USB adapters from Linux guests. That lowers exposure immediately and is especially sensible for legacy dongles retained “just in case.” It also avoids assigning a physical Wi-Fi radio with a long-lived driver defect to a system that has no operational need for it.

CVE-2026-68350 is a targeted kernel fix, not a reason for Windows administrators to patch every PC or disable WSL networking. The concrete action is narrower: find Linux instances that drive an Atheros AR9170 USB adapter with

, verify the distributor’s backport status, and update the guest or host kernel before returning that hardware to service.