CVE-2026-68371 Affects TI Linux USB, Not Windows or WSL2

The newly published CVE record from kernel.org, now carried by NIST’s National Vulnerability Database, describes a deceptively small fault in

: the driver calls

on

, a pointer it borrows from the platform device rather than one for which it acquired its own reference. Releasing that borrowed reference can leave the platform device with an unbalanced Device Tree node count, turning normal later cleanup or access into a potential memory-lifetime problem.

For Windows administrators, the practical conclusion is straightforward: Windows itself is outside the affected software scope, and WSL2’s Linux VM does not normally own or probe a physical OMAP2430 USB controller. The systems requiring attention are Linux deployments on hardware that actually uses this OMAP MUSB driver, particularly custom embedded builds whose kernel maintenance process may lag behind upstream stable releases.

The bug is an ownership error, not a USB input flaw​

Linux Device Tree nodes are reference-counted objects. A kernel function that obtains a node through an API that explicitly returns a referenced object must eventually balance that acquisition with

. But

belongs to the platform device; assigning it into a local

variable does not create another reference for the caller to dispose of.

According to the CVE description,

took that borrowed pointer and released it on both successful and error exits. The platform device still retained the pointer after the release, despite no longer necessarily retaining a valid reference count behind it. That is the condition the patch removes: it stops treating the platform device’s node as if the probe function owned it.

The distinction is important for security triage. This is not a remotely reachable USB-stack bug that a plugged-in device can trigger on a typical PC. It is a kernel-side resource-management defect reached while the OMAP2430 glue driver initializes an on-chip MUSB controller from firmware-described hardware. Any real impact depends first on the relevant driver being built and loaded, then on the matching TI platform and Device Tree configuration being present.

The CVE has no NVD CVSS score, CVSS vector, CWE classification, or public exploitation information as of August 11, 2026. That absence does not make the code error harmless, but it does mean no authority has yet characterized it as a known privilege-escalation, denial-of-service, or remotely exploitable vulnerability. Treating an unscored kernel CVE as proof of practical compromise risk would go beyond the published record.

This is the second repair in the same probe path​

The more revealing context is that this driver has already received a separate fix for the same local variable. CVE-2026-63906, published in July, addressed a use-after-free condition in

by moving

later, after the final use of

, on both normal and error paths.

The Linux kernel mailing-list patch for CVE-2026-63906 identified the earlier defect clearly:

was released and then accessed afterward. The stable patch removed the early release near the MUSB child-device setup and placed releases near the function’s successful return and error cleanup. Independent mirrors of the stable-tree diff show that exact movement.

CVE-2026-68371 now makes the deeper correction. The earlier repair assumed the reference had to be released eventually; the new CVE says the reference was never owned by

in the first place. Its patch removes the probe function’s

calls rather than merely changing their position.

That sequence matters to maintainers who backport fixes selectively. Applying only the July use-after-free patch can eliminate an early dereference of a released node while preserving the underlying ownership imbalance. Applying only the later fix would remove the improper releases, but a tree carrying intermediate local changes should still be reviewed against both upstream changes. This is a paired-fix history, not two interchangeable descriptions of one bug.

There is one reference that still must be released: the Device Tree node returned by

for the optional

property. That function returns a separately referenced child node, and the CVE explicitly says that release remains correct. The patch is narrowly targeted; it does not remove Device Tree cleanup wholesale, only cleanup for an object that the driver never acquired.

The affected-version data needs careful reading​

The NVD record identifies the original regression in the history following Linux commit

, associated with the OMAP2430 probe-resource regression fix. It also lists stable-tree fixes by commit identifier and names fixed stable releases including Linux 6.6.151, 6.12.101, 6.18.42, and 7.1.6, with the upstream development line represented through 7.2-rc5.

Those release numbers are more useful than the CVE’s raw Git ranges for operations teams, but they are not a substitute for checking a distribution kernel changelog. Enterprise and device vendors commonly backport an upstream patch into a kernel package that retains an older-looking base version. A product shipping, for example, a vendor-maintained 6.6 build can be fixed even when

does not resemble 6.6.151.

Conversely, a board-support package may advertise a newer kernel baseline yet carry a heavily customized USB subtree. Embedded vendors and in-house product teams should verify the actual

source or confirm the relevant stable commit in their source manifest. The decisive test is whether the driver still calls

for the local alias of

.

The record’s version modeling also reflects the awkward reality of Linux CVE tracking: the code is tracked as a Git-history issue with branch-specific stable fixes, rather than as a simple universal “all versions before X” condition. That is normal for kernel maintenance, but it makes automated scanners prone to noisy results if they compare only version strings.

What Windows and WSL2 users should do​

Native Windows installations do not ship or run the Linux

driver, so CVE-2026-68371 does not call for a Windows Update, Defender action, registry change, or USB-device restriction. Passing a USB device into WSL2 also does not make the guest become an OMAP2430 platform: the vulnerability concerns the guest kernel binding an on-chip TI controller described by its own firmware Device Tree.

Windows users who develop embedded Linux images, maintain ARM board farms, or use WSL2 to build kernels for TI OMAP hardware should separate the build host from the target. The Windows host and ordinary WSL distribution are not the vulnerable endpoint; the target image is, if it deploys the affected driver and has not incorporated the patch.

For maintainers of the affected embedded products, the practical response is limited:

• Update to a vendor kernel package that includes the CVE-2026-68371 fix, or backport the upstream stable correction into the maintained kernel branch.
• Check that the prior CVE-2026-63906 use-after-free correction is also present if the product’s tree inherited the intermediate placement of of_node_put(np).
• Do not remove the of_node_put() call for the separately obtained ctrl-module phandle node, because that reference is legitimately acquired and still needs balancing.

No distribution security bulletin or independent exploit report for CVE-2026-68371 had surfaced in the material available at publication. The immediate operational task therefore belongs to embedded Linux maintainers: ensure the borrowed platform-device node is no longer released in

, then ship that corrected kernel through the normal device-image update channel.