Patchlage

CVE-2026-80780

CVE CVE-2026-80780EUVD EUVD-2026-71423Published 2026-09-04T15:12:52.000Z

What the advisory describes

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>

Source: EUVD (ENISA), in the words of the advisory.

Products the advisory names

These come from the advisory itself, not from any check we performed.

The versions shown are the advisory's own. Patchlage compares no version numbers and derives no judgement from them — which version is installed is something a person has to look up.

Carried in the product catalogue

An estate covering these products can be recorded in Patchlage. An advisory about them appears in the next morning's situation report.

Does this concern one of your customers?

This page cannot answer that — it does not know your estate. Whoever has recorded their environments gets the answer the morning after publication, together with a paragraph they can forward to the customer unedited.

Try it for 28 days

Patchlage reports hits and suspected hits. About everything else this system says nothing — neither this page nor the situation report ever claims that an estate is safe.