CVE-2026-68360

What it actually does

Race condition between hid_input_report and post-io-start probe failure path allows use-after-free of driver structures when hid_hw_stop is called without first stopping device IO.

Why it matters to the business

Kernel memory corruption on systems using affected Corsair hardware monitoring devices can cause crashes, data corruption, or local privilege escalation; low exploit maturity reduces immediate ransomware risk but still requires prompt patching on Linux servers and workstations with this hardware.

How an attack unfolds

An attacker with local access or the ability to trigger repeated device probe failures (for example by presenting a malformed or disconnecting Corsair device during initialization) forces the race between ongoing input reports and the failed-probe cleanup path, resulting in a freed object being accessed after hid_hw_stop.

How to fix it

Update to a kernel containing the fix that calls hid_device_io_stop before hid_hw_stop in the corsair-cpro driver; rebuild and reboot any affected systems; disable the corsair-cpro module if hardware is not required.

How to confirm the fix worked

Confirm the patch is present by inspecting the corsair-cpro probe function for the hid_device_io_stop call immediately before hid_hw_stop; test probe failure paths with the device connected and disconnected; run kernel memory-safety tools or fuzzing focused on HID probe sequences.

Typical attack path

1. Attacker gains local execution or physical access to the target system
2. Triggers driver probe for the corsair-cpro device
3. Arranges for probe to fail after hid_device_io_start but before full initialization
4. hid_input_report continues to reference now-freed structures
5. Use-after-free is reached leading to memory corruption or control-flow hijack

How to detect it

Monitor kernel logs for oops, warnings, or stack traces referencing corsair_cpro or hid_hw_stop during device probe; look for repeated HID device attach/detach events followed by crashes; examine crash dumps for use-after-free signatures in the hwmon or HID layers.

What your security team should do

• Apply the corrected kernel version to all Linux hosts that may load the corsair-cpro module
• Prioritize servers and high-value endpoints; schedule within normal patch windows given low EPSS and no KEV listing
• Audit systems for presence of Corsair CP/series power supplies or monitoring devices
• Consider blacklisting the module on systems without the hardware