Linux Kernel Fix Addresses NZXT Smart Device CVE-2026-68359

The National Vulnerability Database published the record on August 10, 2026, based on kernel.org’s disclosure. Its description is unusually direct about the failure mode: the driver starts HID device I/O, later encounters a probe failure, and calls

without first stopping I/O. Because

does not itself shut down the incoming device-I/O path,

can still run against driver state that teardown has begun to release.

The correction is small — call

before

— but the placement is the point. It closes the interval in which a USB HID report can arrive after the driver has decided initialization failed.

The bug is in teardown after a failed device probe​

The vulnerable sequence is not a normal fan-curve update or a routine sensor read. It is an error-path race during probe, the point at which Linux recognizes a connected device and initializes its driver. The bad outcome requires the

driver to have started device I/O, then fail later in setup, while an input report is concurrently delivered through the HID layer.

That sequence makes this a narrower problem than a remotely reachable network service vulnerability, but “narrower” is not the same as harmless. A use-after-free occurs when code accesses an object after its allocated memory has been released or repurposed. In kernel space, that can produce a crash, data corruption, or — depending on what conditions an attacker can control around the device and memory layout — a route to elevated code execution.

The public record does not include an NVD CVSS score, a CWE classification, a known-exploitation status, or a proof-of-concept reference as of August 11. Administrators should not fill those blanks with an invented severity rating. The evidence supports a concrete conclusion: this is a real kernel memory-safety fix in a driver that handles a USB-connected cooling controller, but public scoring and exploitation analysis have not caught up with publication.

The important technical correction is also a reminder of a common driver-development trap. Stopping a HID device at a high level is not automatically the same thing as quiescing the lower-level reporting path. The updated code explicitly stops I/O before it tears down HID hardware state, ensuring queued or incoming reports cannot race the cleanup path.

Upstream lists fixed kernel floors, not distro package names​

Kernel.org’s CVE data says the issue affects the

driver beginning with Linux 5.17. It identifies patched upstream release lines at:

• Linux 6.6.148 and later in the 6.6 stable series.
• Linux 6.12.101 and later in the 6.12 stable series.
• Linux 6.18.42 and later in the 6.18 stable series.
• Linux 7.1.6 and later in the 7.1 stable series.
• Linux 7.2-rc5 and later for the then-current development line.

Those version numbers are the most actionable information in the CVE record, and they expose a detail that typical vulnerability summaries tend to bury: there is no single “fixed Linux version.” The patch was backported into five maintained upstream branches. A system on an older kernel may still be protected if its distribution has independently backported the same change; conversely, seeing a newer-looking vendor package version is not enough unless the package changelog or vendor advisory says the patch is included.

The Linux Kernel Mailing List’s 7.2-rc5 changelog independently shows the

correction entering the release candidate alongside equivalent teardown fixes for NZXT Kraken 3, Gigabyte Waterforce, Corsair Commander Pro, and Corsair PSU hardware-monitoring drivers. That context does not expand the scope of CVE-2026-68359 to those other drivers — each has its own patching and disclosure status — but it shows this was a family of related HID-driver cleanup fixes, not an isolated spelling-level adjustment in one file.

For fleet administrators, the practical check is the installed kernel, not the version of OpenRGB, CoolerControl, Liquidctl, or NZXT CAM. Those programs may be part of how a machine is managed, but CVE-2026-68359 is fixed in the kernel driver. On a running Linux machine,

establishes the kernel release; the distribution’s kernel changelog establishes whether a vendor backport covers a nonmatching upstream version.

Which machines are actually in scope​

The CVE applies only when all of the relevant pieces meet: the machine is running Linux, the

hardware-monitoring driver is present, and compatible NZXT Smart Device v2 hardware is connected and bound to that driver. A Linux server with no such USB cooling controller does not become vulnerable merely because its kernel contains the source file or module package.

That scope matters for Windows enthusiasts because the product name can easily make this look like a Windows cooling-software advisory. It is not. The vulnerable component is a Linux kernel driver, not NZXT CAM on Windows, not the Windows HID stack, and not a Windows 11 security update. A Windows PC that uses NZXT hardware under native Windows is outside the direct code path described by the CVE.

WSL users should separate the same two questions. Running a Linux distribution under WSL does not by itself put the

driver in play; the vulnerable path requires the Linux kernel to expose and bind the relevant USB HID hardware. Organizations using customized WSL kernels, USB device pass-through, or Linux virtual machines with physical USB controller access should inventory the guest kernel and attached device configuration rather than assuming the Windows host’s patch state answers the question.

There is also a difference between a reachable flaw and an exploitable one. The published description establishes a race between device-report handling and a failed driver probe. It does not establish that ordinary physical reconnection of a genuine retail controller reliably triggers the error path, nor does it document a malicious USB device scenario. That uncertainty is why the record should prompt patching and hardware inventory, not claims that every NZXT-equipped desktop is immediately exposed to a turnkey privilege-escalation attack.

Why the CVE arrived after the fixes​

The NVD entry already lists the corrected stable commits and marks the patched kernel releases as unaffected. In other words, the CVE publication on August 10 did not announce a fix that still needs to be written; it assigned and distributed a vulnerability identifier for a repair already landing in maintained kernel branches.

That lag changes the operational priority. Teams running a current stable kernel from one of the listed release lines may already have the source-level correction, while systems pinned to older enterprise, appliance, or custom kernels need verification. Security scanners that key off the newly published CVE may begin raising alerts before every distribution has published matching advisory metadata, so a raw scanner finding should be reconciled against the vendor’s actual kernel build and patch backports.

The upstream record’s affected-version syntax also deserves careful reading. It names Linux 5.17 as the introduction point, then identifies fixed floors in several later branches. It does not mean every kernel numerically below 7.2 is vulnerable. A patched 6.6.148 build is covered; an unpatched 6.6.147 build is not, unless a distributor has applied the fix under a different package revision.

The immediate action is a kernel update and reboot​

Administrators responsible for Linux workstations, gaming systems, lab machines, or appliance images with NZXT Smart Device v2 controllers should move to the distribution’s newest supported kernel package and reboot into it. For self-built kernels, the required change is the teardown ordering in

, and the five stable commits referenced by kernel.org identify the backported fixes.

Do not treat unloading and reloading the module as a durable mitigation. The race exists in the driver’s initialization failure path, and the corrected ordering belongs in the binary that will be loaded next. Removing or disabling the

module can reduce exposure where hardware monitoring is unnecessary, but it also removes Linux-side telemetry and controller support rather than resolving the defect.

The next meaningful milestone is distribution-level packaging: once vendors ship kernels incorporating Linux 6.6.148, 6.12.101, 6.18.42, 7.1.6, or their equivalent backports, the remaining task is deployment. For affected machines, this CVE ends when the running kernel — not merely the installed package database — contains the fix.