CVE-2026-68367 Linux USB Gadget Bug Does Not Affect Windows Hosts

The National Vulnerability Database published the record on August 10, 2026, using kernel.org’s description and stable-tree references. The upstream Linux stable commits confirm that the defect is a teardown race: deferred work that sets up a USB interface can continue after the gadget function has been disconnected, disabled, or freed, then dereference memory that no longer belongs to it.

For Windows administrators, the practical line is clear: a Windows PC that merely plugs a USB device into its own port is not running the vulnerable code. A Windows system can be the host connected to an affected Linux gadget, but the fault executes on the Linux device configured to impersonate a USB storage target. Standard WSL 2 deployments are also unlikely to be in scope, because WSL’s USB support is built around USB/IP pass-through rather than exposing the Windows machine as a USB peripheral through a physical device-controller interface.

The race is in a specialized USB device-mode path​

Linux supports two fundamentally different USB roles. Most desktops, laptops, and servers act as USB hosts: they enumerate keyboards, disks, phones, and other attached devices. The code affected by CVE-2026-68367 instead serves systems acting in USB gadget or device mode, where Linux itself appears to another machine as a USB device.

The

function is particularly specialized. It joins Linux’s target subsystem to the USB gadget framework so that a device-mode Linux system can export storage through BOT, the older USB mass-storage protocol, or UAS, the higher-performance SCSI protocol used by many modern external drives. Kernel documentation describes USB gadget configurations as user-space-created compositions of device functions, typically configured through ConfigFS and then bound to a USB Device Controller.

This means the affected population is narrower than “every Linux machine with USB.” It includes purpose-built embedded hardware, development boards with OTG or peripheral-capable ports, appliance designs, and custom deployments that deliberately configure the Target Core Module USB gadget function. An ordinary Linux workstation with a USB-A port and no USB gadget controller is not using this path. Nor is a typical Linux server simply because it has USB storage support enabled.

The kernel’s own original commit history provides useful context: the USB target gadget was introduced to expose target-framework-backed storage via USB, supporting BOT and UAS. That heritage explains both the exposure condition and the Windows relevance. A Linux device in this configuration can be plugged into a Windows host and look like a storage peripheral, but Windows remains the consumer of the device protocol; the vulnerable lifecycle management is on the Linux side.

Deferred setup outlived the gadget it was configuring​

The vulnerability arose because

postponed part of alternate-interface setup to a workqueue task. In USB terms, the

path handles a host request to select an alternate interface setting—here, effectively switching or enabling the gadget’s storage protocol behavior and endpoints. The function intentionally returned a delayed status response, then completed endpoint setup later from process context.

That asynchronous design created two races during teardown.

First, a disconnect or ConfigFS-driven removal could free the private

object while the delayed worker still held a pointer to it. If the worker then ran, it could access freed heap memory. The validation supplied with the CVE records a Kernel Address Sanitizer report identifying a slab use-after-free in

; the allocation path came from configuring the function, while the free path came from unlinking it through ConfigFS.

Second, the USB composite device tracks a pending delayed control-transfer status. A disconnect can clear that state while the worker is preparing to report setup completion. The vulnerable ordering could therefore leave the delayed worker racing to complete a control request that teardown had already invalidated.

This is a reliability defect with security consequences, rather than a demonstrated remote compromise. A use-after-free can produce a kernel crash, corrupted state, or—depending on memory layout and controllability—worse outcomes. But the published CVE carries no CVSS score, no CWE classification, and no exploit information as of August 11. NVD’s absence of a severity assessment is not a “low” rating; it means the record has not yet been enriched with one.

The record also does not claim that connecting a malicious USB host alone is sufficient to exploit the flaw. Creating and removing the

configuration ordinarily involves privileged control over ConfigFS and the USB gadget setup. In practice, the most credible exposure is where an administrator, provisioning system, management daemon, or another privileged service enables this storage-gadget function and can be induced to churn its configuration or disconnect state at the wrong time. Treating it as a generic plug-in-a-malicious-device attack would overstate what the evidence currently establishes.

The fix avoids a deadlock while cancelling work​

The straightforward response to a worker using freed data would be to call

during teardown and wait for the worker to stop. The stable-tree patch cannot do that in every affected path because disabling the USB function occurs while the composite device lock is held; sleeping until the worker finishes under that lock risks deadlock or lock-order trouble.

Instead, the patch adds a small state machine around delayed alternate-setting work. If the work is still queued and has not begun running, teardown cancels it and performs cleanup immediately. If it is already executing, teardown marks it cancelled and lets the worker perform final cleanup itself. The worker checks the cancellation state before it touches the final delayed-status operation.

The patch also takes the composite device lock while it checks cancellation and completes delayed status. That closes the second race: disconnect can no longer clear the pending delayed-status state in the gap immediately before the deferred worker signals successful completion.

This is more than defensive pointer cleanup. The corrected code coordinates ownership of a USB control transaction between the teardown path and the deferred worker. Without that ownership rule, neither side can know safely whether it is responsible for cleaning up state or completing a request.

Five upstream stable branches have the repair​

NVD lists the vulnerable code as present from Linux 3.5 onward and identifies five corrected stable lines:

• Linux 6.6 is fixed in 6.6.151.
• Linux 6.12 is fixed in 6.12.103.
• Linux 6.18 is fixed in 6.18.42.
• Linux 7.1 is fixed in 7.1.6.
• The mainline fix appears in Linux 7.2-rc5 and later.

The upstream patch identifies the original USB target-gadget introduction as the historical source of the problem, but the stable updates touch the current split implementation in

and

. That distinction matters for teams auditing custom kernels: searching only for the old target-gadget filename or assuming the issue began with a recent

refactor can produce a false negative.

There are five backports because the patch needed adjustment for branch-specific code differences. One stable commit notes that its context was adapted for Linux 6.12, including differences in the command structure and stream-related code. Administrators should therefore prefer their distribution’s full kernel update over attempting to transplant the upstream change manually across a vendor kernel.

At publication, no distribution-specific advisory or package build was included in the CVE record. That is normal for a newly published upstream Linux CVE, but it leaves an operational gap: the fixed upstream version is not automatically the version installed by Ubuntu, Debian, Red Hat Enterprise Linux, SUSE, embedded-Linux vendors, or a cloud image provider. Vendors may backport the repair into a kernel whose displayed version is older than the upstream fixed release, while custom kernels may remain vulnerable even when a distribution’s standard package is patched.

Windows and WSL administrators should focus on custom gadget builds​

For a conventional Windows fleet, this CVE does not call for a Windows Update action. The component is Linux kernel code and the trigger path relies on USB device-mode storage emulation. A Windows computer attached to a Linux-based USB appliance may experience the appliance disconnecting, resetting, or failing to enumerate if the bug is triggered, but that is an availability problem originating on the appliance.

WSL deserves a narrower reading than the headline “Linux kernel vulnerability” might suggest. Microsoft’s WSL guidance for USB devices uses the

project to attach a physical USB device to a WSL 2 distribution. That lets WSL act as a USB host-side consumer of a forwarded peripheral. It does not make the Windows PC’s physical USB controller expose WSL as a storage gadget to another host. A standard WSL 2 installation therefore lacks the relevant device-mode arrangement.

The exception is a custom WSL kernel or specialized virtualized setup that enables USB gadget support and maps compatible virtual or physical device-controller hardware into the guest. Such configurations are outside normal WSL operation and should be audited like any other custom Linux kernel deployment. The key configuration symbols are

,

,

,

, and

; their presence alone does not prove active exposure, but an enabled

function bound to a USB Device Controller does.

The immediate action for Linux appliance and embedded-device maintainers is to update to the vendor kernel containing this fix, or move to one of the corrected upstream stable releases. Until then, disable or avoid deploying the TCM USB gadget function where it is not required, especially on devices that frequently reconfigure USB roles or are physically exposed to uncontrolled host connections.