CVE-2026-80780 in Linux
Summary
by MITRE • 09/04/2026
In the Linux kernel, the following vulnerability has been resolved:
HID: pidff: fix OOB write when hid->inputs is empty
hid_pidff_init_with_quirks() derives its input_dev from
list_entry(hid->inputs.next, struct hid_input, list)
without first checking that hid->inputs is non-empty. The list member of struct hid_input is at offset 0, so on an empty list list_entry() yields &hid->inputs itself and the following hidinput->input load reads an unrelated member of struct hid_device. dev is then a type-confused pointer, and force-feedback init writes through it: each set_bit(FF_*, dev->ffbit) stores 8 bytes at dev + 192, past the end of the object dev actually aliases, and input_ff_create() adds further writes of a heap pointer and two function pointers.
Until hid-universal-pidff the only caller was hid_pidff_init() from usbhid, which runs under HID_CLAIMED_INPUT and therefore always has at least one hid_input. universal_pidff_probe() starts the device with HID_CONNECT_DEFAULT & ~HID_CONNECT_FF and then calls hid_pidff_init_with_quirks() directly whenever the descriptor carries a PID usage page, bypassing that gate. A report descriptor whose only application collection is on HID_UP_PID leaves hid->inputs empty while hid_connect() still succeeds through the hidraw claim, so probe reaches the unguarded list_entry().
The write happens in the USB probe path, on the hotplug workqueue, so plugging in a malicious device is enough to trigger it; no attacker software and no logged-in user are required. KASAN reports an 8-byte out-of-bounds write in hid_pidff_init_with_quirks() reached from universal_pidff_probe().
Check for an empty list before deriving dev and return -ENODEV, as the other HID force-feedback drivers already do. universal_pidff_probe() propagates the error and unwinds.
Discovered by XBOW, triaged by Baul Lee <[email protected]>
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/05/2026
The Linux kernel contains a critical out-of-bounds write vulnerability within the Human Interface Device force-feedback subsystem, specifically in the hid_pidff_init_with_quirks function. This flaw arises from an improper validation of input device structures before dereferencing them for memory operations. The root cause lies in the use of list_entry to derive an input_dev pointer from a linked list without first verifying that the list is non-empty. When the hid->inputs list is empty, the list_entry macro returns a pointer to the hid->inputs structure itself rather than a valid hid_input object. Because the list member within struct hid_input is located at offset zero, this results in type confusion where subsequent operations treat a portion of the parent hid_device structure as if it were an input device structure.
This memory corruption manifests when force-feedback initialization proceeds to write data through the incorrectly derived pointer. Specifically, calls to set_bit for various FF_* flags result in eight-byte writes at an offset past the end of the actual object boundaries. Furthermore, the subsequent invocation of input_ff_create performs additional heap-based writes involving pointers and function addresses. These unauthorized memory accesses can lead to kernel instability, data corruption, or potentially arbitrary code execution depending on the state of the affected memory regions. The vulnerability is classified under CWE-787: Out-of-bounds Write, as it involves writing beyond the allocated boundaries of a buffer due to incorrect pointer arithmetic and lack of bounds checking.
The exploitability of this flaw is significantly heightened by its location within the USB probe path, which executes on the hotplug workqueue during device connection events. This architectural placement means that an attacker does not require prior authentication or local user interaction to trigger the vulnerability. By simply connecting a maliciously crafted HID device with a specific report descriptor containing only a PID usage page application collection, the system can be forced into this vulnerable code path. The universal_pidff_probe function initiates the device connection process and directly calls the affected initialization routine when such descriptors are detected, bypassing previous safeguards that relied on different claim states to ensure input structures were present.
From an offensive security perspective, this vulnerability aligns with ATT&CK technique T1059: Command and Scripting Interpreter if leveraged for initial access via physical proximity attacks, or more accurately reflects the exploitation of driver vulnerabilities in system software components often associated with hardware-based attack vectors. The lack of required user interaction places it firmly within remote code execution scenarios facilitated by physical device insertion, a common threat vector in high-security environments where unauthorized peripherals may be introduced to corporate networks.
To mitigate this risk, kernel developers have implemented a check for an empty input list before attempting to derive the device pointer from the linked structure. If no inputs are present, the function now returns -ENODEV instead of proceeding with unsafe memory operations. This change ensures that universal_pidff_probe correctly propagates the error code and unwinds the initialization process safely. System administrators should apply kernel updates containing this fix immediately to prevent exploitation via malicious HID devices. Maintaining up-to-date system patches is essential as these low-level driver flaws can serve as entry points for deeper system compromise when combined with other vulnerabilities or privilege escalation techniques.