CVE-2026-68368 Fixes Linux USB NCM Kernel Memory Leak

The defect is in the Linux USB gadget implementation of CDC-NCM, the USB Network Control Model protocol used when a Linux system presents itself to another machine as a USB network adapter. This is not a bug in the ordinary USB host path used to plug a keyboard, storage drive, phone, or development board into a PC. The attacker is the USB host on the other end of an NCM gadget connection.

Kernel.org’s published patch, authored by Sonali Pradhan and signed into the stable trees by Greg Kroah-Hartman, shows why the distinction matters: malformed NCM transfer blocks could make the kernel copy bytes outside the declared protocol block into a newly constructed network packet. In the vulnerable path,

can copy adjacent data from

into the network socket buffer.

For organizations that use Linux-based USB gadget appliances, embedded systems, development boards, phone-like devices, or custom USB Ethernet setups, this is a patch-now issue. For typical Windows desktops, it is not a Windows kernel vulnerability. The meaningful Windows-adjacent exposure is a specialized WSL or virtualized Linux configuration that has been customized to operate as a USB gadget, rather than ordinary WSL USB passthrough.

A malformed USB network block can cross the intended boundary​

CDC-NCM transports Ethernet frames inside Network Transfer Blocks, or NTBs. The receiving code in

parses the host-provided header, determines the declared block length, finds individual datagrams within the block, and copies those payloads into network buffers.

Before this fix, the routine checked a datagram’s length against

, which limits the maximum Ethernet frame size it expects to handle. But it did not establish the equally important relationship between the datagram’s offset and length and the declared NTB block boundary. A frame may be smaller than the maximum permitted size yet still point beyond the block that supposedly contains it.

The patch closes several variations of that gap:

• It rejects a transfer that does not contain enough remaining bytes even to hold an NTB header before parsing it.
• It handles an NTB block_len field of zero by treating the remaining input as the block, rather than trying to advance through a zero-byte block.
• It rejects a declared block length larger than the data actually left in the socket buffer.
• It rejects a datagram whose length would extend past the end of its declared block.
• It tightens checks for subsequent datagram indexes while decoding multiple NTBs received in one socket buffer.

Those checks turn a memory-boundary assumption into an enforced condition. The important practical result is that a hostile USB host can no longer claim that payload data exists where the transfer did not actually provide it, then induce the gadget-side networking code to package adjacent kernel memory as received network data.

Kernel.org identifies two historical commits relevant to the vulnerable behavior: one that added earlier bounds checks to

, and another that added support for decoding multiple NTBs in a single unwrap call. The latter explains the secondary-header case: after one block has been processed, the code must validate the next block against the remaining bytes, not against a length field supplied by the peer.

This is an information-exposure bug first, not a demonstrated code-execution bug​

The published CVE description describes copying adjacent kernel memory into a network socket buffer. That is an information disclosure primitive: data that should remain in internal kernel memory may become payload visible to networking code and, depending on the configuration and traffic path, potentially to a user-space consumer or back across the USB network link.

Neither the NVD record nor the kernel commit claims remote code execution, privilege escalation, or a known exploitation chain. The record also has no NIST CVSS v3, v4, or CWE classification as of August 11, 2026. That absence is significant: no severity number has been assigned by NVD, and a high score should not be invented simply because the issue occurs in kernel code.

Still, “local physical access” would undersell the relevant trust boundary. In the vulnerable role, the target Linux system deliberately exposes a USB networking function and accepts protocol data from the attached host. That host may be a laptop used for field servicing, a compromised workstation connected to embedded equipment, another device on a lab bench, or a computer managed by a different team. Where USB gadget networking is used as an administrative or provisioning channel, the host is an input source that must be treated as potentially hostile.

The patch’s inclusion in stable kernel trees is also a useful signal. It was not left as an upstream-only cleanup; the commit carries a stable-tree request and has been backported into multiple maintained branches. That does not establish exploitation, but it does establish that maintainers consider the correctness and security impact suitable for broad deployment.

NVD’s version data needs more work​

The newly published NVD record names five stable fix commits, including the upstream commit and backports. It also says the vulnerable code is in

. Those are useful identifiers for distribution maintainers and for teams maintaining custom kernels.

But the affected-version block is not clean enough to use as a patching decision by itself. One portion of the record says Linux versions before 5.9 are unaffected, while another portion marks specific releases in the 4.9, 4.14, 4.19, and 5.4 series as affected. Both statements cannot describe one simple uninterrupted version range.

The most plausible explanation is that the CVE combines two related defect paths with different introduction points: the multiple-NTB parsing problem is tied to the later multi-NTB support, while the datagram-versus-block validation gap can apply to older code. But that is an inference from the fix history and the conflicting data, not an explicit NVD resolution. The current entry does not explain the split.

That leaves a practical instruction: do not close this ticket merely because a scanner sees a kernel version below 5.9 and applies the NVD’s “unaffected” range mechanically. Check the exact distribution advisory, its source package changelog, or whether the vendor kernel contains the relevant stable backport. For self-built kernels, compare

against the final patch logic.

NVD presently lists fixed stable release points of Linux 6.6.148, 6.12.101, 6.18.42, 7.1.6, and the 7.2-rc5 development line. Those entries are useful reference points for upstream users, but enterprise distributions commonly backport security patches without adopting the corresponding upstream release number. A distribution kernel branded with an older base version can therefore be protected; a version-string-only check is not enough.

Windows and WSL users should distinguish USB host support from USB gadget mode​

Windows itself is not affected by CVE-2026-68368. The vulnerable source file is Linux’s

function driver, which implements the device-side portion of USB networking. Windows PCs normally act as USB hosts, and the Windows USB stack is outside this CVE’s stated scope.

Microsoft’s WSL documentation describes USB support as attaching a physical USB device to a WSL 2 distribution through USB/IP and

. That is a host-to-guest device-forwarding arrangement: WSL receives access to a connected peripheral. It is not documentation for turning the WSL virtual machine into a CDC-NCM USB peripheral connected to an external host.

As a result, a normal Windows 11 workstation using

for an Arduino, debugger, smartcard reader, or other peripheral is not exercising the vulnerable gadget-side

path merely by attaching a device. Updating WSL remains good practice, but this CVE does not create a reason to treat routine USB passthrough as the affected configuration.

There are two exceptions worth checking. Microsoft supports specifying a custom WSL kernel through

, and developers may build or configure bespoke Linux kernels and virtual hardware arrangements. Teams that have replaced the default WSL kernel, enabled USB gadget-related kernel options, or use WSL in a hardware-development workflow should audit their configuration rather than assume WSL’s ordinary USB behavior applies.

What administrators should do now​

First, establish whether the affected system ever acts as a USB CDC-NCM gadget. Search for USB gadget configuration using ConfigFS,

,

, or

; inspect embedded product configurations, device-mode USB ports, and any scripts that create USB Ethernet interfaces for provisioning or maintenance.

Second, obtain the patched kernel from the system vendor. The NVD record was only published on August 10, and no independent security outlet appears to have reported separate exploitation or distribution-specific rollout timing as of August 11. Vendor advisories and package changelogs will be more useful than generic vulnerability scanners until the version metadata is reconciled.

Third, if an immediate kernel update is unavailable, disable the NCM gadget function or avoid connecting the device-mode USB port to untrusted hosts. This is a narrowly exposed component, so removing the gadget function is a meaningful mitigation without requiring an organization-wide ban on USB peripherals.

The most concrete outcome is simple: systems that export USB Ethernet through Linux’s CDC-NCM gadget stack need the backported fix; systems that only consume USB peripherals do not match the attack direction described by CVE-2026-68368. The remaining problem is inventory accuracy, because NVD’s newly published version ranges currently give incompatible answers for older kernel branches.