CVE-2026-68374: WSL 2 USB Race Fix Lands in Linux 7.2-rc5

The underlying fix is already visible in the Linux 7.2-rc5 release candidate, where it appears as

. Linus Torvalds’ 7.2-rc5 announcement lists the patch under USB maintainer Greg Kroah-Hartman’s changes. The important detail is that the patch fixes concurrent access to cached USB descriptor data during device teardown; it is not a flaw in Windows’ native USB stack.

For administrators, the practical action is straightforward: update Linux kernels when distributors ship the fix, and keep WSL current with

. Do not treat this as a reason to deploy a development kernel or to disable USB across Windows desktops. The record presently supports a targeted mitigation decision, not panic.

The vulnerable path is a read-only USB sysfs file​

Linux introduced the

sysfs attribute to expose a USB device’s Binary Object Store, or BOS, descriptor set. The original Linux USB patch explains that the cached data can include capability descriptors such as WebUSB and Microsoft OS 2.0 platform descriptors. Linux makes the file available only where a USB device has a BOS, normally at a path resembling

.

The design is deliberate: userspace can inspect the cached descriptor bytes without issuing new USB I/O and without elevated privileges. But that read-only convenience created a lifetime problem. The pre-fix

routine fetches the device’s cached

pointer, reads the descriptor length, and copies bytes into the caller’s buffer without taking the USB device lock.

That becomes unsafe if the USB device is disconnected, reset, or otherwise torn down while a process is reading the sysfs file. The teardown path can release or replace the cached BOS object after the reader has obtained its pointer. A read that then continues can access memory whose lifetime has ended.

The Linux 7.2-rc5 patch title says exactly what changes: it adds the missing lock to

. The likely effect is to serialize the sysfs read with USB-device state changes, ensuring that the cached descriptor remains valid through the copy operation.

This is an important distinction from many USB security bugs. The available upstream code shows that the sysfs helper reads a descriptor already cached by the kernel; it does not parse a newly supplied BOS payload each time a user reads the file. The defect is a race around object lifetime, not a confirmed malformed-descriptor parser bug.

A crash is plausible; privilege escalation is not established​

The CVE’s bare title and the upstream patch establish that a locking defect existed. They do not establish a working exploit chain, a severity rating, affected kernel ranges, or a demonstrable path to privilege escalation. At the time of publication, no independent exploit analysis or distribution advisory for CVE-2026-68374 was available.

That missing information matters. A use-after-free-style race in kernel code can range from a hard-to-repeat local denial of service to a security boundary bypass, depending on allocation behavior, timing, architecture, compiler hardening, and the surrounding code. It would be irresponsible to call this a root exploit based on the patch title alone.

There is, however, a realistic reliability consequence. A local process that repeatedly reads a qualifying device’s

file while another event removes the device can exercise the unsafe timing window on kernels without the lock. In a physical-device scenario, that could mean a cable pull, hub reset, power interruption, or re-enumeration. In more specialized environments, a virtualized or redirected USB device may present equivalent connect-and-disconnect behavior.

The public documentation gap is unusually visible here. NVD assigned and published CVE-2026-68374, yet its own entry was unreachable with a gateway failure several hours later. The upstream release candidate lists the fix but does not explain security impact. Until the CNA record, NVD metadata, or Linux distribution advisories fill in the blanks, teams should document the issue as an unscored kernel race rather than inventing a severity.

WSL 2 is the Windows case worth checking​

Windows itself does not run the Linux USB core. A standard Windows 10 or Windows 11 installation using USB peripherals normally is therefore outside the scope of this CVE.

WSL 2 changes the picture because it runs a Linux kernel. Microsoft’s WSL documentation says USB device attachment relies on USB/IP and the

project rather than native USB attachment. An administrator shares a physical Windows USB device with

, then a user attaches it to the active WSL 2 virtual machine with

. Once attached, Linux tools in WSL can enumerate and interact with that device.

That is the configuration where the Linux USB sysfs path becomes relevant. Arduino flashing, smart-card readers, embedded-device debugging, FPGA tools, serial adapters, lab hardware, and other USB passthrough workflows are more exposed than a typical WSL development environment that never attaches physical USB hardware.

Microsoft’s public WSL kernel releases currently list

as the latest rolling-LTS release. Linux 7.2-rc5 is newer than that upstream baseline, and Microsoft has not published a CVE-2026-68374-specific WSL advisory or said that the USB locking fix has been backported. That does not prove every current WSL kernel is vulnerable; downstream maintainers routinely backport security fixes without adopting the next upstream version number. It does mean that administrators cannot infer protection merely from seeing a current-looking WSL release tag.

On a Windows endpoint, check the running WSL kernel rather than the Windows build number:

wsl --status
wsl --version
wsl --update

Inside a WSL distribution, use:

The version check establishes what is running, but it cannot by itself prove whether a downstream vendor has backported this specific patch. For managed fleets, the authoritative answer will be the advisory or changelog from Microsoft, Canonical, Red Hat, SUSE, Debian, or the vendor providing the kernel package.

The affected population is narrower than “all USB users”​

The vulnerable helper exists only for a USB device with an available BOS. The original USB sysfs implementation notes that the kernel does not request BOS data from devices reporting a USB specification version below 2.01, and the file is hidden when no BOS has been cached.

That sharply narrows the condition from “any USB device” to devices that expose the relevant descriptor set and a process reading this specific sysfs file during a concurrent teardown event. A keyboard, mouse, storage drive, or USB serial adapter is not automatically implicated simply because it is connected.

It also means conventional Windows endpoint controls do not need to be rewritten around this CVE. USB device-control products, port restrictions, and hardware inventory policies remain useful for their own reasons, but they are not a substitute for updating the Linux kernel where the vulnerable code runs.

For WSL operators, the proportionate temporary control is to avoid attaching untrusted or unnecessary USB devices into WSL 2 until Microsoft clarifies backport status, particularly on shared developer machines and systems that let less-trusted users access the WSL environment. Disabling USB/IP wholesale is generally excessive unless the system’s threat model already treats USB passthrough as prohibited.

What to watch for next​

The patch’s presence in Linux 7.2-rc5 confirms that upstream has a fix, but a release candidate is not a stable-kernel rollout. The next meaningful milestones are the final Linux 7.2 release, stable backports to supported Linux series, and downstream advisories that name package versions.

Administrators should watch for three concrete facts that are still absent: the first fixed upstream commit, the vulnerable kernel version range, and a CVSS assessment backed by an actual technical impact statement. Until then, the defensible conclusion is modest but clear: CVE-2026-68374 is a real USB-core synchronization fix, it can matter to USB-enabled WSL 2 workloads, and the public CVE record currently gives operators far less deployment guidance than it should.