Cloudanix VulnDB

CVE-2026-80780

None

CVSS

—

EPSS

0.2%

Published

Sep 4, 2026

CISA due date

—

Cloudanix analysis

Next patch cycle SSVC: Track

Plugging a specially made USB device into a Linux computer can corrupt memory inside the operating system kernel, potentially letting an attacker take control without any user action.

Exploitation
Physical Access
Attacker needs
Physical Access
Complexity
Low
Impact
Full Compromise
Component
OS kernel
Class
Memory Corruption
Remediation
Patch
Effort
Low
Patch risk
Low

What it actually does

Out-of-bounds write via type-confused pointer when hid_pidff_init_with_quirks derives an input device from an empty hid->inputs list, allowing arbitrary memory writes including heap pointers and function pointers during force-feedback initialization in the USB probe path.

Why it matters to the business

Kernel memory corruption on systems using affected HID force-feedback drivers can lead to crashes, privilege escalation, or arbitrary code execution simply by attaching a malicious USB device, forcing emergency patching and potential downtime for any Linux-based hardware that supports PID devices.

How an attack unfolds

An attacker crafts a USB HID device whose report descriptor contains only a PID usage page. When the device is plugged in, universal_pidff_probe connects via hidraw without populating hid->inputs, then calls the unguarded list_entry path; the resulting type-confused pointer causes set_bit and input_ff_create writes past object bounds on the hotplug workqueue with no user interaction required.

How to fix it

Update to a kernel containing the fix that adds an empty-list check in hid_pidff_init_with_quirks returning -ENODEV; rebuild and deploy the updated kernel on all affected systems; disable the universal-pidff module if the functionality is not required.

How to confirm the fix worked

Confirm the patched kernel source contains the list_empty check before list_entry in hid_pidff_init_with_quirks; test by attaching a PID-only descriptor device and verifying probe returns -ENODEV without kernel taint or KASAN reports; monitor dmesg for successful device rejection.

Typical attack path

  1. Craft malicious HID report descriptor containing only HID_UP_PID application collection
  2. Attach device to target system triggering usbhid probe
  3. universal_pidff_probe succeeds via hidraw claim leaving hid->inputs empty
  4. hid_pidff_init_with_quirks performs unchecked list_entry yielding type-confused pointer
  5. force-feedback initialization performs 8-byte OOB writes and stores function pointers

How to detect it

Review kernel logs and dmesg around USB hotplug events for KASAN reports citing hid_pidff_init_with_quirks or universal_pidff_probe; inspect audit logs for unexpected USB device enumeration followed by oops or panic; correlate with presence of PID usage pages in attached HID descriptors.

What your security team should do

  • Prioritize kernel upgrade on all Linux endpoints that load hid-pidff or universal-pidff within 30 days
  • Block unknown USB HID devices via USBGuard or udev rules until patches are applied
  • Add kernel module denylist for universal_pidff on systems that do not require PID force feedback
  • Enable KASAN or similar memory safety instrumentation on test systems to validate the fix

The record

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>

Affected packages

Ecosystem Package Introduced Fixed