CVE-2026-90330 in Linux
Summary
by MITRE • 09/17/2026
In the Linux kernel, the following vulnerability has been resolved:
HID: logitech-hidpp: Fix FF device cleanup on init failure
hidpp_ff_init() creates the input force-feedback device with input_ff_create(), then allocates the HID++ FF private data, effect ID array, and workqueue.
If any of those allocations fail after input_ff_create() succeeds, the function returns an error without destroying the FF device. Add an unwind path that frees the private allocations made by hidpp_ff_init() and calls input_ff_destroy() for failures after input_ff_create() succeeds.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 09/17/2026
The Linux kernel's Human Interface Device subsystem contains a resource management flaw within the Logitech HID++ force-feedback driver, specifically in the initialization routine known as hidpp_ff_init. This function is responsible for setting up support for advanced gaming peripherals that utilize force feedback effects to provide tactile responses during gameplay or interaction. The core of the vulnerability lies in an asymmetric error handling path where the driver creates a kernel input device node before allocating all necessary internal data structures required for its operation. Specifically, the code first invokes input_ff_create to register the force-feedback device with the Linux input subsystem, which increments reference counts and establishes system-level bindings. Following this registration, the function proceeds to allocate private memory regions including HID++ specific context data, an array to track effect identifiers, and a workqueue for asynchronous processing of feedback effects.
The critical technical flaw occurs when one of these subsequent allocation steps fails due to resource exhaustion or other transient kernel errors. In such scenarios, the current implementation returns an error code immediately without performing any cleanup operations on resources already acquired by input_ff_create. Because the device node has been successfully registered with the subsystem but its associated private data and workqueue remain allocated yet orphaned, a memory leak is introduced into the kernel space. More critically, this state can lead to use-after-free vulnerabilities or undefined behavior if subsequent driver operations attempt to access the partially initialized structure or if the system attempts to unload the module while holding references to incomplete objects. This represents a classic instance of improper resource cleanup during error handling paths, where early success in one subsystem component is not matched by corresponding teardown logic upon failure in dependent components.
From a security and stability perspective, this vulnerability impacts system reliability rather than providing direct remote code execution vectors under normal circumstances. However, the accumulation of leaked kernel memory can lead to gradual degradation of system performance over time, potentially resulting in denial-of-service conditions through resource exhaustion. Attackers with local access could theoretically exploit repeated allocation failures to accelerate memory leakage, although practical exploitation requires precise timing and control over memory pressure scenarios. The issue is categorized under CWE-401 which denotes missing release of memory after effective usage, highlighting the failure to properly deallocate resources when an operation fails partway through execution. This type of defect undermines the robustness of kernel drivers by violating the principle that every acquisition must have a corresponding and guaranteed release path regardless of success or failure outcomes.
To mitigate this vulnerability, developers must implement comprehensive unwind logic within the initialization function. The fix involves adding conditional checks after each allocation step to ensure that if input_ff_create has already succeeded but subsequent allocations fail, the driver correctly invokes input_ff_destroy to deregister the device from the subsystem and frees all previously allocated private data structures including the effect ID array and workqueue. This ensures atomicity in resource management where either all resources are successfully acquired or none remain dangling after a failure. System administrators should ensure their kernels are updated with patches that include this corrected initialization sequence, thereby restoring proper lifecycle management for HID++ force-feedback devices and preventing potential memory leaks during device enumeration or driver loading phases under high-load conditions.