CVE-2026-93189 in Linux
Summary
by MITRE • 09/17/2026
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.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 09/17/2026
The Linux kernel contains a critical concurrency vulnerability within the Human Interface Device core subsystem that results in use-after-free conditions during driver initialization failures. This flaw arises from an improper sequence of operations when handling input device lifecycle management, specifically involving the interaction between hid_device_io_start and hid_hw_stop functions. When a HID driver's probe function successfully calls hid_device_io_start to enable input delivery but subsequently fails at a later initialization step, it triggers an error unwind path that invokes hid_hw_stop. The core issue lies in the fact that this unwinding process frees internal structures such as struct hidraw via hidraw_disconnect while asynchronous HID reports may still be actively processing on other CPU cores. These in-flight operations continue to dereference the now-freed memory through callbacks like hidraw_report_event, leading to undefined behavior and potential system instability or privilege escalation depending on the context of the corrupted data access.
This vulnerability represents a class-wide API misuse rather than a regression from a single commit, which explains why no specific Fixes tag is associated with it in the kernel source history. The affected drivers acquired their hid_device_io_start calls independently over several years without consistent adherence to proper shutdown sequencing. An audit of the codebase reveals that approximately half of all callers utilizing this API pattern are exposed to this risk. Specifically, while seven drivers correctly implement a matching call to hid_device_io_stop before invoking hid_hw_stop, eight others including corsair-psu, corsair-cpro, nzxt-kraken3, nzxt-smart2, gigabyte-waterforce, hid-logitech-dj, hid-nintendo, and hid-mcp2221 fail to perform this critical quiescing step. This inconsistency creates a fragmented security posture where some hardware configurations are protected while others remain vulnerable to race conditions during device removal or initialization failure scenarios.
The operational impact of this vulnerability is significant as it allows for memory corruption in kernel space through use-after-free exploits. Attackers with local access could potentially leverage these races to execute arbitrary code, escalate privileges, or cause denial-of-service conditions by triggering specific timing windows where the freed structure is accessed. The complexity increases because the race condition depends on multi-core execution states and asynchronous report processing, making it difficult to reproduce consistently without specialized tools like syzbot which identified the initial instances in drivers such as corsair-psu. The lack of centralized enforcement means that driver developers must manually remember to stop input delivery before disconnecting devices, a requirement often overlooked during rapid development cycles or when adapting existing code patterns for new hardware support.
To mitigate this vulnerability, the Linux kernel maintainers have implemented a centralization strategy within hid_hw_stop itself rather than relying on individual driver implementations. The fix ensures that if hdev->io_started is true upon entry to hid_hw_stop, the function automatically invokes hid_device_io_stop before proceeding with disconnect operations. This approach guarantees consistent behavior across all drivers regardless of their internal implementation details and eliminates the burden from developers to manually manage this synchronization point. For existing correctly implemented drivers where io_started remains false during normal operation, the guard short-circuits effectively preserving original performance characteristics while adding safety for edge cases involving probe failures.
From a classification perspective, this vulnerability aligns with CWE-416 Use After Free and CWE-362 Concurrent Execution Using Shared Resource with Improper Synchronization. The attack vector corresponds to ATT&CK technique T1059 Command and Scripting Interpreter if exploited via kernel module injection or T1078 Valid Accounts for privilege escalation scenarios enabled by the memory corruption. Security practitioners should ensure that systems running affected kernel versions are updated promptly as patches become available through standard distribution channels. Until updates are applied, monitoring for unusual kernel oops messages related to hidraw structures may provide early detection indicators of exploitation attempts targeting these specific HID driver implementations.