CVE-2026-80780: HID: pidff: fix OOB write when hid->inputs is empty
In the Linux kernel, the following vulnerability has been resolved:
HID: pidff: fix OOB write when hid->inputs is empty
hidpidffinitwithquirks() derives its inputdev from
listentry(hid->inputs.next, struct hidinput, 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 listentry().
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>
Affected Software
Event History
Frequently Asked Questions
Which initialization path can reach the vulnerable condition?
The vulnerable path is universal_pidff_probe(), which calls hid_pidff_init_with_quirks() directly for a descriptor carrying a PID usage page. The earlier usbhid caller runs under HID_CLAIMED_INPUT, which ensures at least one hid_input is present.
What device characteristics are needed to trigger the out-of-bounds write?
The HID device must have a report descriptor carrying a PID usage page while hid->inputs is empty. universal_pidff_probe() starts the device with HID_CONNECT_DEFAULT with force-feedback connection disabled, then invokes PID force-feedback initialization directly.
What is the resulting memory corruption?
An empty input list causes the code to treat the hid_device list head as a hid_input, producing a type-confused dev pointer. Force-feedback setup then writes FF capability bits out of bounds and input_ff_create() performs additional writes including a heap pointer and two function pointers.