CVE-2026-68361: Patch Linux Corsair PSU Driver UAF

The newly published kernel.org CVE record, now mirrored by the National Vulnerability Database, describes a race during a failed probe of the Corsair PSU device. After the driver enables HID input, its error-cleanup path could call

while incoming USB HID reports were still being delivered. That sequence can free HID raw-device state while the HID input path is about to use it, producing a kernel-memory use-after-free.

The fix is already upstream and has been backported to the kernel stable branches identified by the CVE record. As of August 11, the NVD entry lists fixed kernel releases 6.6.148, 6.12.101, 6.18.42, 7.1.6, and 7.2-rc5. It has no CVSS score, CWE classification, known-exploitation entry, or distribution package status yet. That lack of enrichment should not be mistaken for a clean bill of health; it means the public record has not been scored or fully translated into vendor package advisories.

The bug is in cleanup, after USB input has already started​

The vulnerable code is in

, which exposes power-supply telemetry through Linux’s

interface. On supported devices, it gives monitoring tools access to voltage rails, current, power draw, fan RPM, temperatures, and PSU uptime. The driver communicates with the power supply as a USB HID device, not through a generic motherboard sensor chip.

The defect is a teardown ordering problem. During

, the driver starts device I/O with

. If a subsequent part of initialization fails, the error path tears down the HID device with

. But

disconnects HID functions such as

; it does not, on its own, guarantee that delivery of an input report has ceased.

That leaves a small but consequential window. An inbound HID report can enter

, then continue through

to

after

has been freed. The kernel’s KASAN memory-safety instrumentation caught precisely that condition: a slab use-after-free while trying to lock memory associated with the now-freed

object.

The patch closes the window in the correct order. If device I/O has been started, the driver now first calls

, clears its

state under the HID input lock, and only then calls

. In practical terms, it tells the HID layer to quiesce reports before removing the structures to which those reports may be delivered.

This is a real memory-safety fix, but it is not evidence that ordinary sensor polling can suddenly corrupt a system. The documented triggering condition is a failed driver probe after I/O begins. A machine that loads the driver successfully and continuously reads PSU telemetry is not, by that fact alone, exercising the vulnerable cleanup path.

Affected hardware is limited to Corsair’s HID-enabled PSU families​

Linux’s own

driver documentation identifies supported hardware as Corsair HXi and RMi series power supplies with a compatible HID interface. The list includes HX550i, HX650i, HX750i, HX850i, HX1000i, HX1200i, HX1500i, RM550i, RM650i, RM750i, RM850i, and RM1000i variants, with some legacy and newer-series distinctions.

That matters for fleet triage. The CVE’s affected range begins with Linux kernel 5.11 because that is where the Corsair PSU HID controller driver entered the kernel tree. But kernel version alone is an overinclusive test. A server, workstation, virtual machine, or container host running an affected kernel is not exposed through this driver unless all of the following are true:

• The kernel was built with the corsair-psu driver or can load it as a module.
• A supported Corsair USB HID power supply is physically attached or passed through to the Linux instance.
• The device reaches the driver’s initialization path and encounters a failure after input I/O has started.

For most enterprise Linux servers, that combination will be unusual. Rack systems generally use server-grade power supplies managed through BMC, IPMI, Redfish, or vendor-specific platform interfaces, rather than a Corsair consumer/prosumer PSU exposed as a USB HID device. The likely population is desktop Linux, lab machines, enthusiast workstations, and small-office or homelab systems that use compatible Corsair hardware.

Windows users should read this as a Linux host and Linux kernel issue, not a Windows kernel vulnerability. Windows does not use Linux’s

driver. The relevant WindowsForum audience is therefore administrators operating Linux workstations, dual-boot systems, dedicated monitoring nodes, or Linux infrastructure alongside Windows estates.

The report points to device-mediated risk, not a demonstrated network exploit​

Syzkaller, the kernel fuzzing project that tracked the underlying crash, lists the failure as a high-priority KASAN slab use-after-free and records a C reproducer. Its tracking page marks a peripheral trigger as applicable, which fits the vulnerable path: the bug is reached through USB HID input from a PSU-class device.

That is materially different from a remotely reachable service flaw. Neither the CVE record nor the upstream patch description demonstrates a network-delivered exploit, a privilege-escalation chain, arbitrary code execution, or exploitation in the wild. The NVD has also not assigned a CVSS vector. The right operational description today is a kernel memory-safety flaw reachable through a specific local hardware-driver path, with exploitability and severity still unscored publicly.

There is nevertheless a reason to patch it rather than dismiss it as a harmless crash. Use-after-free bugs sit in a serious class because freed memory can be reused unpredictably. In the best case, this produces an oops, a driver failure, or a reboot. Under favorable memory-layout and device-control conditions, such defects can sometimes become more than denial-of-service bugs. The current record does not establish that outcome here, and administrators should not assign one on speculation.

The exposure model also means physical and supply-chain controls matter. A hostile or maliciously modified USB HID peripheral is more relevant than an unauthenticated internet client. On systems where USB device access is controlled, the attacker would generally need the ability to attach, emulate, or pass through a device that can participate in the probe sequence. That still includes some meaningful cases: shared labs, repair benches, insecurely exposed USB ports, and virtualization setups where USB devices are assigned to guest systems.

This was one of several nearly identical driver fixes​

The Corsair PSU patch did not arrive in isolation. The Linux 7.2-rc5 pull request also carried closely related fixes for the

,

,

, and

hardware-monitoring drivers. Each addressed the same basic ordering error: stopping HID-backed hardware monitoring after a failed probe without first stopping device I/O.

That pattern changes how maintainers should interpret CVE-2026-68361. It is not a flaw in Corsair power-supply telemetry logic specifically; it is a repeated misuse of HID teardown semantics by several

drivers. The driver-side fixes are appropriately targeted, but the clustering shows why lifecycle code deserves as much scrutiny as normal I/O paths. Initialization failures are often treated as obscure edge cases, yet they are exactly where partially initialized objects, asynchronous input, and cleanup routines meet.

Syzkaller’s history adds useful context. It recorded the original use-after-free report in late April 2026 and references several proposed approaches, including an attempted HID-core-level solution to quiesce input during

. The accepted Corsair PSU fix instead makes the driver explicitly stop I/O before invoking the broader HID shutdown routine. That is a safer backporting posture for stable branches: the patch is small, confined to the affected driver, and does not alter teardown behavior for every HID consumer.

The trade-off is that other HID-backed drivers must independently follow the same contract. The five fixes bundled in the hardware-monitoring pull request suggest that maintainers have already found several that did not.

Patch by distribution package, not by the kernel string alone​

The NVD’s fixed-version list is useful for upstream tracking but is not an instruction to install a vanilla kernel tarball. Enterprise and consumer distributions commonly backport individual security fixes while retaining an older-looking base version. Conversely, a system with a numerically newer kernel can still be vulnerable if its vendor has not incorporated the relevant stable commit.

Administrators should check the changelog and security status of the installed distribution kernel package for CVE-2026-68361 or for the upstream subject, “hwmon: (corsair-psu) Stop device IO before calling hid_hw_stop.” Where vendor documentation is not yet available, the conservative option for machines using the driver is to install the latest supported kernel package supplied by the distribution and reboot into it.

A quick exposure check is also worthwhile before escalating the issue across a fleet:

lsmod | grep corsair_psu
modinfo corsair_psu
dmesg | grep -i corsair

A missing loaded module does not prove permanent safety—modules can autoload when hardware appears—but it helps distinguish a broad kernel inventory finding from a system with the affected driver actually active. On machines deliberately using Corsair PSU telemetry, confirm the deployed package includes the backport rather than assuming an upstream release number resolves the question.

The immediate consequence is straightforward: update Linux systems that monitor a supported Corsair HID power supply, reboot into the vendor-fixed kernel, and keep USB peripheral access controlled on machines where that hardware is present. For systems without the driver or compatible PSU, CVE-2026-68361 belongs in the vulnerability inventory, not at the top of the emergency patch queue.