UBUNTU-CVE-2026-80780: Medium severity ubuntu/linux-hwe-edge vulnerability

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>