CVE-2026-80780

What the bug is

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>

Where it lives

The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.

drivers/hid/usbhid/hid-pidff.c

What this is

USB HID PID DRIVERS (USB WHEELBASES, JOYSTICKS, RUDDERS, ...)MAINTAINERS section matched on drivers/hid/usbhid/hid-pidff* · linux-input@vger.kernel.org · Maintained

Check it on the machine

grep -wE 'CONFIG_HID|CONFIG_HID_PID|CONFIG_HID_SUPPORT|CONFIG_USB_HID|CONFIG_USB_KBD|CONFIG_USB_MOUSE' /boot/config-$(uname -r)

Reads the booted kernel's own configuration, on the machine and nowhere else. =y is built in, =m is a module, and an is not set line means the code is not there.

Show whether Debian builds this, per release

Debian does not build this code. In 5 releases below, every kernel flavour Debian publishes has the switch off, so the vulnerable file is compiled into no kernel binary Debian ships.

• bookworm, trixie, forky, sid, bookworm · linux-6.12n

n

not enabled on any flavour - this release does not build the code

Build switches

CONFIG_HID, CONFIG_HID_PID, CONFIG_HID_SUPPORT, CONFIG_USB_HID, CONFIG_USB_KBD, CONFIG_USB_MOUSE

Reads as

all on means the file is compiled; any one off means it is not.

From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS kbuild Makefiles Debian linux-config packages

Signals

Published

2026-09-04 (44 days ago)source

CVSS

no vector published, unrated

Attack vector

not published

EPSS

0.18%, higher than 7.2% of all CVEssource

CISA KEV

not listedthe KEV catalogue

Debian urgency

unimportantsource

Subsystem

drivers/hid

Upstream fixes

The versions the CNA records as introducing and fixing this, and the commit for each. source

Introduced	Fixed in	Commit
6.6.88	6.6.156	2e0471bf3ab2
6.12.24	6.12.108	ad9330f7e74a
6.15	6.18.47	4529c03c3da8
6.15	7.1.11	d416eeb7d016
6.15	7.2.1	86b63adfa5e1
6.15	7.3	67bb1074e3d2
6.13.12	0	0
6.14.3	0	0

Debian advisories