CVE-2026-68361

What it actually does

Use-after-free in the corsair-psu hwmon driver caused by a race between hid_input_report() and the failure path after hid_device_io_start() but before proper IO teardown; hid_hw_stop() alone does not stop pending input reports, allowing a freed hidraw structure to be accessed.

Why it matters to the business

Systems using Corsair power supplies with the affected Linux kernel driver can experience kernel crashes or memory corruption, leading to denial of service or potential local privilege escalation; the issue affects only a narrow set of hardware but requires prompt kernel updates on affected machines.

How an attack unfolds

An attacker with local access or the ability to trigger repeated probe failures (for example by unplugging or faulting the USB HID device during initialization) causes corsairpsu_probe() to call hid_hw_stop() while an input report handler still holds a reference to a soon-to-be-freed hidraw object, resulting in the use-after-free.

How to fix it

Apply the upstream fix that calls hid_device_io_stop() (when io_started) before hid_hw_stop() inside the corsairpsu_probe() error path; rebuild and boot a patched kernel; no user-space configuration changes are required.

How to confirm the fix worked

Confirm the presence of the commit that adds the hid_device_io_stop() call before hid_hw_stop() in drivers/hwmon/corsair-psu.c; load the module and exercise probe failure paths while monitoring for KASAN reports or absence of the race; verify with kernel version strings that contain the fix.

Typical attack path

1. Attach or enumerate a Corsair PSU device that binds the corsair-psu driver
2. Force corsairpsu_probe() to reach hid_device_io_start()
3. Induce probe failure after IO start but before successful completion
4. Trigger a concurrent input report that accesses the freed hidraw structure
5. Achieve slab use-after-free leading to kernel panic or controlled memory corruption

How to detect it

Review kernel logs for KASAN use-after-free reports referencing hidraw_report_event, hid_report_raw_event, or corsairpsu_probe; inspect dmesg and audit logs around USB device attach events for hid_hw_stop and probe failure sequences; no network or file-based artifacts exist.

What your security team should do

• Prioritize kernel updates on any host that loads the corsair-psu module
• Monitor for future backports into distribution kernels and apply them within normal patch windows
• If the hardware is not in use, blacklist the corsair-psu module to reduce attack surface
• Include the module in automated kernel regression and fuzzing test suites