CVE-2026-90329 in Linux
Summary
by MITRE • 09/17/2026
In the Linux kernel, the following vulnerability has been resolved:
HID: synchronize input before cleaning up a failed probe
hid_device_io_start() allows reports to run concurrently with probe. If the probe subsequently fails, __hid_device_probe() releases driver resources and clears hdev->driver without first excluding those report callbacks.
For example, a report may enter hidraw_report_event() while the failure path frees the associated hidraw object, leading to a use-after-free when the report takes the object's list lock.
Stop input before performing failed-probe cleanup. This reacquires driver_input_lock and waits for any report callback already in progress.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/17/2026
The Linux kernel’s Human Interface Device subsystem contains a race condition vulnerability within the device probe mechanism that can lead to use-after-free errors during hardware initialization failures. The core issue stems from an improper synchronization order when handling failed probes for HID devices. Specifically, the function hid_device_io_start permits input reports to be processed concurrently with the driver probe routine. When the probe operation fails and execution enters the error handling path within __hid_device_probe(), the kernel proceeds to release driver resources and clears the hdev->driver pointer without first ensuring that any ongoing report callbacks have completed or been excluded from further processing. This lack of synchronization creates a window where active input handlers may continue to operate on data structures that are in the process of being deallocated, resulting in memory corruption and potential system instability.
This vulnerability is classified under CWE-416, which describes use-after-free conditions arising when software continues to use memory after it has been freed. In this specific context, a report event may enter hidraw_report_event while the failure path is actively freeing the associated hidraw object. As the report handler attempts to acquire the list lock for that now-freed object, it triggers a use-after-free scenario. Such conditions can lead to kernel panics, denial of service, or potentially allow an attacker with local access to execute arbitrary code by exploiting the corrupted memory state. The attack vector typically involves triggering a hardware probe failure while simultaneously generating input events, which requires physical interaction with vulnerable HID devices or emulation thereof in virtualized environments.
From a threat modeling perspective aligned with MITRE ATT&CK techniques, this vulnerability relates to T1059 Command and Scripting Interpreter if exploited for code execution, but more fundamentally it represents an exploitation of improper resource management (T1486 Data Encrypted for Impact) or privilege escalation pathways through kernel memory corruption. The lack of proper locking during the cleanup phase allows concurrent access that violates expected state consistency, a common pattern in race condition vulnerabilities within operating system kernels.
The resolution involves modifying the probe failure handling logic to stop input processing before performing any resource cleanup. This change ensures that driver_input_lock is reacquired and that all report callbacks currently in progress are allowed to complete or be safely terminated before resources such as hidraw objects are freed. By enforcing this synchronization, the kernel prevents concurrent access to deallocated memory structures during the critical window of a failed probe operation.
To mitigate the risk associated with this vulnerability, system administrators should apply the latest available Linux kernel updates that include this fix. Since the issue resides in core input handling subsystems, it affects all distributions running affected kernel versions. Users relying on HID devices such as keyboards, mice, game controllers, or specialized industrial interfaces are particularly susceptible to instability if probe failures occur under load. Regular patching and monitoring of system logs for unexpected kernel oops or panic messages related to hidraw or input handlers can help identify systems that may have experienced exploitation attempts or stability issues prior to the application of patches.