CVE-2026-98502 in Linux
Summary
by MITRE • 10/18/2026
In the Linux kernel, the following vulnerability has been resolved:
HID: alps: unregister DualPoint Stick input device on remove
alps_input_configured() allocates a second input device ("DualPoint Stick") with input_allocate_device() and registers it, but the alps_driver struct has no .remove handler and input2 is not tracked in hdev->inputs. The default remove path (hid_hw_stop -> hidinput_disconnect) only iterates hdev->inputs, so input2 is never unregistered and leaks on every device removal.
Add a .remove handler that stops the device first (preventing URB callbacks from touching input2 during teardown) and then unregisters input2.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/19/2026
The Linux kernel's Human Interface Device subsystem contains a resource management flaw within the Alps DualPoint Stick driver, specifically involving improper cleanup procedures during device removal. This vulnerability stems from an asymmetry in how input devices are allocated versus how they are released. When the alps_input_configured function initializes the hardware, it successfully allocates and registers a secondary input device known as the DualPoint Stick using input_allocate_device. However, this second device is not added to the hdev->inputs array, which serves as the primary tracking mechanism for managed HID input devices within the kernel's internal data structures. Consequently, when the physical device is disconnected or removed from the system, the standard disconnection routine fails to recognize and clean up this secondary resource.
The operational impact of this flaw manifests as a memory leak that occurs every time an Alps DualPoint Stick device is unplugged or powered down. The default remove path in the HID subsystem relies on hid_hw_stop followed by hidinput_disconnect. This sequence iterates exclusively over the devices listed in hdev->inputs to perform unregistration and cleanup. Because the second input device was allocated but never registered into this list, it remains orphaned in memory. Over time, repeated connection and disconnection cycles will consume increasing amounts of kernel memory, potentially leading to resource exhaustion on systems with frequent peripheral usage or limited memory resources. This represents a classic case of improper resource deallocation where allocation succeeds but the corresponding free operation is bypassed due to missing tracking metadata.
From a vulnerability classification perspective, this issue aligns with CWE-401, which describes a failure to release memory after it has been successfully allocated. The lack of proper cleanup mechanisms allows for gradual degradation of system stability rather than an immediate crash or security breach, though persistent leaks can eventually lead to denial-of-service conditions by exhausting available kernel heap space. In the context of attack vectors such as MITRE ATT&CK, this type of resource exhaustion could theoretically be leveraged in a Denial of Service scenario if an attacker with physical access or control over device insertion events can trigger repeated removal cycles to degrade system performance.
The resolution involves modifying the alps_driver structure to include a dedicated remove handler that explicitly manages the lifecycle of both input devices. This custom handler ensures that the secondary DualPoint Stick is properly unregistered and freed from memory during teardown. Crucially, the fix also implements a sequence where the device is stopped first before unregistering it. Stopping the device prevents any pending USB Request Blocks or asynchronous callbacks from accessing the now-invalidating input2 structure during the cleanup phase. This sequential approach eliminates race conditions that could otherwise lead to use-after-free vulnerabilities if URB callbacks attempted to interact with the input device while it was being deallocated. By ensuring strict ordering of stop and unregister operations, the patch restores robust resource management practices consistent with kernel coding standards for HID drivers.