CVE-2026-68349: Patch Linux carl9170 Wi-Fi Kernel Crash

The National Vulnerability Database added the record on August 10, 2026, with no CVSS score, no CWE classification, and no NIST assessment yet. The underlying kernel fix is already concrete, however. As detailed in the Linux wireless mailing list patch submitted by Tristan Madani, the driver could append too many bytes from a second USB receive transfer into a fixed 65,535-byte socket buffer, causing the kernel’s

guard to fire.

This is a security fix, but the public record does not establish a remotely exploitable Wi-Fi attack. The vulnerable code consumes USB transfers from the AR9170 device and sits at the firmware-to-driver boundary. A malformed or compromised adapter, modified device firmware, USB emulation environment, or a sufficiently abnormal device response is much closer to the documented trigger than a nearby person merely transmitting unusual 802.11 frames.

A four-line patch closes a long-lived receive-path flaw​

The vulnerable function,

, maintains a failover buffer when a receive frame crosses USB-transfer boundaries. It tracks how many bytes are still needed in

, then appends data from the next transfer before passing the reassembled packet onward.

Before the fix, the append operation used the entire size of the second transfer, stored in

. It did not limit that copy to the number of bytes actually needed to complete the pending frame. If the failover buffer was nearly full and the next USB transfer was also large, the code could push the total beyond the allocated 65,535 bytes.

The correction changes the copy length to the smaller of

and

. In practical terms, the driver now takes only the tail bytes needed to finish the incomplete frame and leaves the surplus to be processed as subsequent input. The accounting still subtracts the full transfer length, which is deliberate: it signals that reconstruction is complete while preventing the over-copy itself.

The patch identifies the original introduction point as commit

, described as “carl9170: 802.11 rx/tx processing and usb backend.” Linux kernel archive material places that initial driver work in 2010, making this a defect that survived for roughly 16 years in a legacy-but-still-shipped driver.

The result reported by the patch author is

, a kernel panic protection mechanism that catches attempts to grow a socket buffer past its allowed end. That makes a denial of service the demonstrated consequence. A buffer overflow in kernel space should never be dismissed solely because the reported failure is a panic, but neither the CVE record nor the patch series provides an exploit proof, a privilege-escalation claim, or evidence of exploitation in the wild.

The affected hardware is old, but it has not disappeared​

supports USB devices built around the Atheros AR9170 802.11n chipset. Linux Wireless documentation describes it as the open-firmware replacement for the older

driver, covering draft-802.11n USB hardware. That puts the issue primarily in older USB Wi-Fi dongles, embedded deployments, lab hardware, long-lived industrial images, and systems where a legacy adapter has been retained because it still works.

Examples historically associated with the AR9170 family include certain D-Link, Netgear, TP-Link, SMC, and AVM USB adapters, but the name on the plastic is not enough to determine exposure. Vendors often reused product names and device revisions with entirely different chipsets. Administrators should inspect the actual Linux driver in use rather than build an inventory from model names.

On a Linux endpoint where wireless hardware is attached, these commands are the useful first check:

lsmod | grep carl9170
modinfo carl9170
ethtool -i wlan0

The first command identifies an already loaded module. The second confirms whether the installed kernel provides it. The third can tie a particular wireless interface to its active driver, although interface names may not be

on modern distributions.

A system can contain the module without actively using it, and an adapter can be present without the module loaded. Those are different risk states. The vulnerable receive code becomes relevant when the kernel is driving an AR9170-class USB device through

; a server fleet with no such adapters does not become exposed merely because its kernel package includes the module.

Stable fixes exist, but package names are the trap​

The CVE record supplied by kernel.org marks the flaw as affecting the code from Linux 2.6.37 onward and identifies fixed upstream/stable points in Linux 6.6.148, 6.12.101, 6.18.42, 7.1.6, and the development milestone 7.2-rc5. It also lists five stable-tree commits, reflecting that the small fix was backported across maintained kernel lines rather than left only in the development branch.

Those version numbers are useful for kernel builders and teams tracking an upstream stable branch directly. They are not sufficient patch guidance for enterprise distributions. Red Hat Enterprise Linux, SUSE Linux Enterprise, Ubuntu LTS, Debian stable, Amazon Linux, appliance vendors, and embedded distributions regularly backport security fixes without replacing the visible upstream base version. A machine reporting an older-looking

may already contain the correction; conversely, a vendor-custom kernel needs its own advisory or changelog checked.

The proper operational sequence is:

• Identify whether carl9170 is loaded or available on systems with USB Wi-Fi hardware.
• Apply the vendor’s current kernel security update and reboot into that kernel where the adapter is in service.
• Verify the running kernel after reboot rather than only confirming that a package was downloaded.
• For custom kernels, confirm that the relevant stable commit or the bounded-copy change in drivers/net/wireless/ath/carl9170/rx.c has been integrated.

The NVD record does not name distribution packages, does not list affected product models, and does not provide a severity score. That absence matters. It means security teams should not invent a fleet-wide emergency based on the word “buffer overflow,” but should also not wait for a future numeric rating before patching affected endpoints. The remediation has already landed upstream and is operationally low-risk: it changes a single receive-path copy limit.

The broader patch series points to a device trust-boundary problem​

Madani’s April 2026 mailing-list series was titled “firmware trust boundary hardening.” This CVE was its third patch. The accompanying work addressed other missing validation around fields controlled by the device firmware, including an oversized command-response path and an out-of-bounds read in transmit-status handling.

That context changes how this CVE should be read. This is not a generic Linux networking flaw that applies to every Wi-Fi chipset or every system using

. It is a defect in one driver’s assumption that data arriving from a USB-connected wireless device will fit the state it has already allocated.

For security teams, that creates a practical classification: treat affected adapters as untrusted peripherals with firmware, not as passive network interfaces. The distinction is especially relevant for USB devices sourced from unknown channels, equipment received from third parties, development benches that pass devices among users, and embedded products that use AR9170 hardware internally. In those environments, a kernel crash can become both an availability problem and a useful primitive for someone testing deeper driver flaws.

The fact that several 2026 fixes trace back to the same 2010 backend commit is also a reminder that code age is not evidence of maturity. The driver has long been functional enough to survive in distributions, while its handling of malformed device responses continued to receive scrutiny. The appropriate response is to patch rather than assume a legacy adapter is too obscure to matter.

Windows systems need only a targeted WSL review​

Windows itself is not affected by CVE-2026-68349 because the vulnerable code belongs to the Linux

kernel driver. A Windows host using its normal native Wi-Fi driver stack does not load Linux kernel modules and has no exposure from this CVE.

There is one limited Windows-adjacent case worth checking: WSL 2. Microsoft’s WSL documentation allows USB devices to be explicitly bound and attached to a Linux distribution through

, and WSL supports custom kernels and custom kernel-module VHDs. A team that has passed a physical AR9170 USB adapter into WSL and configured a kernel with

could therefore create the affected Linux path inside the WSL virtual machine.

That is an unusual configuration, not the normal WSL deployment model. Still, developer workstations, hardware-validation labs, and security research environments are precisely where old USB wireless adapters and USB/IP passthrough tend to linger. On those systems, run the same module and interface checks inside the WSL distribution, then update the WSL kernel or custom kernel build as appropriate.

For everyone else, this is a focused Linux kernel maintenance item: patch systems that actually use Atheros AR9170 USB Wi-Fi hardware, verify the vendor backport rather than trusting the apparent kernel version, and do not mistake an unscored NVD entry for either a non-issue or a confirmed remote takeover.