AZL-99650

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