CVE-2026-93189: HID: core: quiesce input in hid_hw_stop() to prevent use-after-free
In the Linux kernel, the following vulnerability has been resolved:
HID: core: quiesce input in hidhwstop() to prevent use-after-free
A driver's probe calls hiddeviceiostart() to enable input delivery, then fails at a later initialization step and unwinds via hidhwstop(). The unwind frees struct hidraw via hidrawdisconnect() while in-flight HID reports may still be running on another CPU, dereferencing the freed object through hidrawreportevent(). syzbot reports the resulting use-after-free for the corsair-psu HID driver.
Edward Adam Davis posted a per-driver fix for corsair-psu that adds an explicit hiddeviceiostop() before hidhwstop() in the probe error path ("hwmon: prevent packets from going to driver for probe", 2026-04-28). Auditing the tree shows 15 drivers call hiddeviceiostart(); 7 also call hiddeviceiostop() and 8 do not:
drivers calling hiddeviceiostart() without a matching hiddeviceiostop() before hidhwstop(): drivers/hwmon/corsair-psu.c (fix posted by Edward) drivers/hwmon/corsair-cpro.c drivers/hwmon/nzxt-kraken3.c drivers/hwmon/nzxt-smart2.c drivers/hwmon/gigabytewaterforce.c drivers/hid/hid-logitech-dj.c drivers/hid/hid-nintendo.c drivers/hid/hid-mcp2221.c
Roughly half of all callers of the API are exposed. Centralize the quiesce in hidhwstop() so callers do not have to remember the matching stop: if a driver has left hdev->iostarted true on entry, call hiddeviceiostop() before hiddisconnect().
For the 7 drivers that already call hiddeviceiostop() correctly, hdev->iostarted is false on entry, the guard short-circuits, and behavior is unchanged.
No Fixes: tag because the affected drivers gained their hiddeviceiostart() calls independently over years; the bug is a class-wide API misuse rather than a regression from one commit.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
Ensure HID core quiesces input in hid_hw_stop() to prevent use-after-free when drivers misuse hid_device_io_start() without matching hid_device_io_stop() in their probe/error paths (class-wide API misuse hardening).
Linux HID core hid_hw_stop() quiesce input = quiesce input to prevent use-after-free during hid_device_io_start()/hid_device_io_stop() lifecycle
Event History
Frequently Asked Questions
What conditions are required for the use-after-free to occur?
A HID driver's probe must enable input delivery with hid_device_io_start(), then fail during a later initialization step and unwind through hid_hw_stop(). HID reports must also still be in flight on another CPU while hidraw is being disconnected and freed.
Which drivers are explicitly identified as lacking a matching input stop before hid_hw_stop()?
The provided audit explicitly names corsair-psu, corsair-cpro, nzxt-kraken3, nzxt-smart2, gigabyte_waterforce, hid-logitech-dj, and hid-nintendo. It states that eight drivers lacked the matching stop, but the supplied driver list is truncated before the eighth name.
What change addresses the affected probe error paths?
Input delivery should be explicitly stopped with hid_device_io_stop() before calling hid_hw_stop() during probe-error unwinding. This prevents in-flight reports from reaching hidraw_report_event() after hidraw has been freed.