Cloudanix VulnDB

CVE-2026-93189

High · 8.8

CVSS

8.8

EPSS

0.3%

Published

Sep 17, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A bug in how the Linux kernel handles certain hardware devices can let an attacker crash the system or run code by plugging in a malicious device during startup.

Exploitation
Adjacent Network
Attacker needs
None
Complexity
Low
Impact
Full Compromise
Component
OS kernel
Class
Use After Free
Remediation
Patch
Effort
Medium
Patch risk
Low

What it actually does

Use-after-free in HID core: hid_hw_stop() frees hidraw objects while in-flight reports may still dereference them via hidraw_report_event() on another CPU when drivers call hid_device_io_start() without a matching stop before unwinding on probe failure.

Why it matters to the business

Kernel memory corruption or crashes on Linux systems using affected HID hardware drivers; successful exploitation can lead to denial of service or local privilege escalation with physical or adjacent access to USB HID devices.

How an attack unfolds

An attacker connects a specially crafted HID device (or emulates one) that triggers a driver's probe path calling hid_device_io_start() followed by a later failure; the unwind via hid_hw_stop() frees structures while pending reports are still processed, causing the UAF.

How to fix it

Update to a Linux kernel containing the centralized quiesce logic in hid_hw_stop(); ensure all callers of hid_device_io_start() are paired correctly before calling hid_hw_stop().

How to confirm the fix worked

Verify kernel source contains the io_started guard and hid_device_io_stop() call inside hid_hw_stop(); confirm affected drivers no longer exhibit the probe error path UAF under syzkaller or similar fuzzing.

Typical attack path

  1. Attacker presents malicious or triggering HID device to the system
  2. Affected driver (e.g., corsair-psu, nzxt-kraken3, logitech-dj) calls hid_device_io_start() during probe
  3. Probe fails at a subsequent initialization step
  4. hid_hw_stop() is invoked without prior hid_device_io_stop(), freeing hidraw while reports may still be active
  5. Concurrent CPU processes a report and dereferences the freed object

How to detect it

Search kernel logs for KASAN or use-after-free reports mentioning hidraw, hid_hw_stop, or hidraw_report_event around device connect events; inspect USB HID probe failure paths in affected drivers.

What your security team should do

  • Prioritize kernel update on all systems exposing HID devices to untrusted hardware
  • Audit custom or out-of-tree HID drivers for proper io_start/io_stop pairing
  • Monitor for kernel oops or KASAN reports involving hidraw_report_event or hid_hw_stop

The record

In the Linux kernel, the following vulnerability has been resolved: HID: core: quiesce input in hid_hw_stop() to prevent use-after-free A driver's probe calls hid_device_io_start() to enable input delivery, then fails at a later initialization step and unwinds via hid_hw_stop(). The unwind frees struct hidraw via hidraw_disconnect() while in-flight HID reports may still be running on another CPU, dereferencing the freed object through hidraw_report_event(). 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 hid_device_io_stop() before hid_hw_stop() in the probe error path ("hwmon: prevent packets from going to driver for probe", 2026-04-28). Auditing the tree shows 15 drivers call hid_device_io_start(); 7 also call hid_device_io_stop() and 8 do not: drivers calling hid_device_io_start() without a matching hid_device_io_stop() before hid_hw_stop(): 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/gigabyte_waterforce.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 hid_hw_stop() so callers do not have to remember the matching stop: if a driver has left hdev->io_started true on entry, call hid_device_io_stop() before hid_disconnect(). For the 7 drivers that already call hid_device_io_stop() correctly, hdev->io_started is false on entry, the guard short-circuits, and behavior is unchanged. No Fixes: tag because the affected drivers gained their hid_device_io_start() calls independently over years; the bug is a class-wide API misuse rather than a regression from one commit.

Affected packages

Ecosystem Package Introduced Fixed