CVE-2026-89624: Linux Kernel HID Use-After-Free Vulnerability

CVE-2026-89624 Overview

CVE-2026-89624 is a use-after-free vulnerability in the Linux kernel's HID universal-pidff driver. The flaw resides in universal_pidff_probe(), which starts a HID device with hid_hw_start() but fails to stop it when force-feedback initialization subsequently fails. The HID core does not unwind the started device on the driver's behalf, leaving the registered hidraw character device pointing to freed memory. An unprivileged local user opening the surviving /dev/hidrawX triggers a use-after-free write, as reported by KASAN. The issue was discovered by XBOW and triaged by Baul Lee.

Critical Impact
Local users with access to a crafted HID device can trigger kernel memory corruption, enabling privilege escalation or denial of service.

Affected Products

Linux kernel HID subsystem (hid-universal-pidff driver)
Distributions shipping the affected kernel prior to the fix commits
Systems exposing /dev/hidrawX to unprivileged users or attaching USB HID devices

Discovery Timeline

2026-09-11 - CVE-2026-89624 published to NVD
2026-09-13 - Last updated in NVD database

Technical Details for CVE-2026-89624

Vulnerability Analysis

The defect lives in the universal_pidff_probe() function of the Linux HID universal-pidff driver. The probe routine calls hid_hw_start() to bring the device online, then attempts force-feedback initialization through hid_pidff_init_with_quirks(). When that initialization returns an error, the function jumps to an exit label that only executes return error without invoking hid_hw_stop().

The HID core's __hid_device_probe() reacts to the probe failure by releasing the devres group, calling hid_close_report(), and setting hdev->driver = NULL. Because the hidraw character device that hid_hw_start() registered through hid_connect() is allocated with kzalloc() and added via cdev_device_add(), it is not devres-managed and survives the cleanup. With hdev->driver cleared, hid_device_remove() also skips hid_hw_stop(), so the hidraw registration outlives the underlying device state on both paths.

Root Cause

The root cause is missing error-path teardown: universal_pidff_probe() treats the failure label as a simple return without reversing the effects of hid_hw_start(). This is a classic Use-After-Free condition. Sibling drivers hid-dr.c and hid-emsff.c, which use the same HID_CONNECT_DEFAULT & ~HID_CONNECT_FF mask, already stop the device on this path.

Attack Vector

An attacker supplies a HID descriptor that carries a PID usage page but no input reports. hidraw claims the device so hid_hw_start() succeeds, while hid->inputs stays empty and force-feedback initialization fails through paths such as missing output reports, allocation failure, pidff_init_fields(), pidff_check_autocenter(), an unusable effect count, or input_ff_create(). After the probe fails, opening the surviving /dev/hidrawX calls hidraw_open() and then hid_hw_open(), which invokes the transport's open callback and takes a spinlock inside the freed object, producing a KASAN-reported use-after-free write.

No synthetic exploit code is provided. Refer to the upstream commits 01d9874e, c457bb51, and ce08c555 for the authoritative patch content.

Detection Methods for CVE-2026-89624

Indicators of Compromise

KASAN reports referencing hidraw_open, hid_hw_open, or the freed HID transport object in kernel logs
Unexpected kernel oops or panic events immediately following USB HID device attachment
Presence of /dev/hidrawX nodes associated with HID descriptors that advertise PID usage pages but expose no input reports

Detection Strategies

Enable KASAN on test kernels to surface use-after-free writes originating in the HID subsystem
Audit kernel package versions against the fix commits 01d9874e, c457bb51, and ce08c555 on affected stable branches
Correlate USB device enumeration events with subsequent hidraw open failures to identify attempts to trigger the flaw

Monitoring Recommendations

Forward dmesg and journald kernel messages to a centralized log platform and alert on KASAN or oops signatures naming hidraw paths
Track USB device attach events via udev and flag descriptors matching the PID-usage, no-input-report pattern
Monitor loading of the hid-universal-pidff module on systems that do not require force-feedback controllers

How to Mitigate CVE-2026-89624

Immediate Actions Required

Apply the upstream Linux kernel patches referenced by commits 01d9874e, c457bb51, and ce08c555
Rebuild or update to a distribution kernel that incorporates the fix and reboot affected hosts
Restrict physical and virtual USB access on multi-user systems and kiosks until the patch is deployed

Patch Information

The fix adds a dedicated error label in universal_pidff_probe() that calls hid_hw_stop() when force-feedback initialization fails after the device has been started. The two earlier gotos continue to return without hid_hw_stop(), since those paths never started the device. See Kernel Git Commit 01d9874, Kernel Git Commit c457bb5, and Kernel Git Commit ce08c55.

Workarounds

Blacklist the hid-universal-pidff module on systems that do not need PID force-feedback support
Tighten permissions on /dev/hidrawX so only trusted service accounts can open the character device
Disable USB host controller ports or apply USBGuard policies on exposed endpoints to block untrusted HID descriptors

bash

# Configuration example: blacklist the vulnerable module
echo 'blacklist hid-universal-pidff' | sudo tee /etc/modprobe.d/blacklist-pidff.conf
sudo depmod -a
sudo update-initramfs -u