CVE-2026-68360: Update Linux for Corsair Commander Pro UAF

The CVE was published by the Linux kernel CNA and entered the National Vulnerability Database on August 10. Its immediate operational message is narrow: this is a Linux driver lifecycle bug, not a Corsair iCUE vulnerability and not a Windows kernel vulnerability. A normal Windows installation does not execute

; Windows users should not go looking for a Corsair firmware update or an iCUE patch in response to this CVE.

For Linux systems that do use the driver, however, the correct response is a kernel update rather than a configuration workaround. NVD’s record identifies fixed stable releases as Linux 6.6.148, 6.12.101, 6.18.42, and 7.1.6, with the upstream fix entering the mainline development branch in Linux 7.2-rc5.

The bug sits in probe failure cleanup, not normal fan control​

The

driver gives Linux hardware-monitoring tools access to the Commander Pro’s fan channels, temperature sensors, voltage readings and PWM controls. Kernel documentation lists support for the Corsair Commander Pro and the Commander Pro implementation in Corsair’s 1000D case. The driver is designed to recognize the USB hardware automatically, so an affected machine can load it as soon as the controller is attached.

The vulnerable sequence occurs during probe—the kernel’s initialization process when it binds the driver to the USB HID device. The driver starts device I/O with

before it has completed several later initialization steps, including detecting connected temperature and fan ports and registering the hwmon device.

If one of those later operations fails, the pre-fix error path closes and stops the HID hardware. But, as the kernel CVE record states,

does not itself stop device I/O. HID input can therefore continue arriving while the failed initialization is being unwound. An input report can reach the driver’s input-report path after the driver state it expects has begun to disappear.

That is the use-after-free: a code path accesses memory after the kernel has released it. Such bugs can produce a crash, memory corruption, or—in the wrong set of circumstances—security impact. The public CVE record does not assign a CVSS score, a CWE classification, an exploitability assessment, or a known-exploitation status. It also does not describe a working exploit against a physical Commander Pro device.

That absence is important. The CVE establishes a real memory-safety defect and a fix, but it does not establish that attaching an ordinary Corsair controller to a desktop gives an unprivileged local user a reliable path to kernel-code execution. Treat it as a patch-management item with kernel-level consequences, rather than inflating an incompletely assessed record into a demonstrated remote compromise.

One missing stop call closes the race​

The repair is small and appropriately specific: call

before

when the probe fails, ensuring the driver quiesces HID traffic before the rest of its teardown proceeds.

The vulnerability is easy to misunderstand because the affected driver already called

and

in its cleanup path. Those function names sound conclusive. The CVE exists because they were not sufficient for the separate I/O state created by

.

The pre-fix source makes the exposure concrete. It starts device I/O, then performs sensor discovery and hwmon registration. Any failure after that point branches to the same cleanup labels. The cleanup did not symmetrically reverse the earlier I/O-start operation. This is a classic asynchronous teardown failure: the initialization thread assumes the device is stopping while an interrupt-driven input path can still deliver data.

The Linux 7.2-rc5 changelog places the Corsair Commander Pro change among four closely related hwmon fixes for Corsair, Gigabyte and NZXT USB HID monitoring drivers. A separate Corsair PSU driver fix also landed in that broader cleanup work. That context indicates kernel maintainers found a repeated shutdown-ordering pattern in drivers using the HID I/O interfaces, rather than an isolated mistake in one fan controller.

There is also an independent syzbot record for a related HID use-after-free in

, reported in April 2026 against the Corsair PSU driver path. The report provides a KASAN-detected crash trace through USB HID input handling and records that the issue was patched upstream. It should not be treated as a proof-of-exploit for CVE-2026-68360: it names a different driver. It does, however, show why driver teardown ordering is more than a theoretical coding concern in this subsystem.

The affected hardware is more limited than the Linux version range​

CVE-2026-68360 affects kernels beginning with Linux 5.9 because that is when the

driver entered the affected history. It does not mean every Linux device running a kernel in that range is exposed in a meaningful way.

The driver’s USB match table identifies Corsair vendor ID

and product IDs

for the Commander Pro and

for the Commander Pro in the 1000D. A system without one of those supported controllers, or one configured so the driver is absent or blacklisted, does not invoke the affected path.

The trigger is constrained further. The race requires device I/O to start and the probe to fail afterward, leaving HID reports able to arrive during cleanup. That makes a mere successful boot with a Commander Pro less relevant than a device initialization failure, a reconnect sequence, an unusual device response, or an environment deliberately engineered to disrupt probing.

None of that is a reason to defer kernel updates on systems where the controller is installed. Kernel use-after-free defects are worth correcting even when the documented trigger looks specialized, particularly on workstations, lab systems, game-server hosts, or virtualization machines where USB hardware may be connected and disconnected frequently. But the scope rules out treating this as an enterprise-wide Linux emergency for fleets that have no compatible Corsair controller.

Stable version numbers need distribution context​

NVD identifies five kernel fixes: four stable-tree backports and the upstream mainline change. Administrators should use the fixed version in their kernel’s branch as the baseline:

• Linux 6.6 users need 6.6.148 or a vendor kernel that has backported the equivalent patch.
• Linux 6.12 users need 6.12.101 or an equivalent vendor backport.
• Linux 6.18 users need 6.18.42 or an equivalent vendor backport.
• Linux 7.1 users need 7.1.6 or an equivalent vendor backport.
• Linux 7.2 development users need 7.2-rc5 or later.

Distribution versioning can complicate a straight comparison. Red Hat, SUSE, Ubuntu, Debian and appliance vendors commonly backport security fixes while retaining an older-looking upstream base version. Conversely, a locally compiled kernel may carry a newer nominal version without a distributor’s security advisory trail. Check the installed package changelog or vendor advisory, then verify the running kernel with

; do not assume that “6.6” alone establishes whether the patch is present.

For source-built kernels, the practical verification is to inspect the

probe cleanup path for

before

. Teams that maintain custom kernel trees should also look for the equivalent change in any vendor-modified version of the driver rather than applying unrelated HID-core patches and assuming the issue is covered.

Windows and WSL users have one unusual edge case​

For a Windows-focused audience, the ordinary answer is simple: Windows itself is outside the affected code path. iCUE and the Windows USB driver stack do not load Linux’s

module.

The exception is WSL 2 or a Linux virtual machine given direct access to the controller. Microsoft documents that USB devices can be attached to WSL 2 through USB/IP and

; once attached, Windows cannot use that device while the Linux environment can interact with it using normal Linux tools. A user who has deliberately passed a Commander Pro through to WSL 2 could therefore place the device in reach of the Linux driver—assuming the WSL kernel configuration includes the hwmon driver.

That setup is unusual for RGB and cooling hardware, and it is not the default WSL experience. Still, it is a useful reminder that a CVE’s operating-system scope follows the kernel handling the hardware, not necessarily the operating system installed on the physical PC.

The next action is concrete: update the Linux kernel on machines with a Corsair Commander Pro or 1000D controller, and confirm that the running distribution build incorporates the relevant backport. Everyone else can record CVE-2026-68360 as a narrowly scoped Linux USB hwmon fix rather than a Windows security incident.