CVE-2026-80780

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 baul.lee@xbow.com