In the Linux kernel, the following vulnerability has been resolved:
HID: pidff: fix OOB write when hid->inputs is empty
hidpidffinitwithquirks() 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 hidinput is at offset 0, so on an empty list listentry() yields &hid->inputs itself and the following hidinput->input load reads an unrelated member of struct hiddevice. dev is then a type-confused pointer, and force-feedback init writes through it: each setbit(FF_*, dev->ffbit) stores 8 bytes at dev + 192, past the end of the object dev actually aliases, and inputffcreate() adds further writes of a heap pointer and two function pointers.
Until hid-universal-pidff the only caller was hidpidffinit() from usbhid, which runs under HIDCLAIMEDINPUT and therefore always has at least one hidinput. universalpidffprobe() starts the device with HIDCONNECTDEFAULT & ~HIDCONNECTFF and then calls hidpidffinitwithquirks() directly whenever the descriptor carries a PID usage page, bypassing that gate. A report descriptor whose only application collection is on HIDUPPID leaves hid->inputs empty while hidconnect() 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 hidpidffinitwithquirks() reached from universalpidffprobe().
Check for an empty list before deriving dev and return -ENODEV, as the other HID force-feedback drivers already do. universalpidffprobe() propagates the error and unwinds.
Discovered by XBOW, triaged by Baul Lee baul.lee@xbow.com
{
"osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/80xxx/CVE-2026-80780.json",
"cna_assigner": "Linux"
}