CVE-2026-89624

What it actually does

A use-after-free write in the Linux kernel HID stack (universal-pidff). After hid_hw_start() succeeds, force-feedback initialization can fail and return without hid_hw_stop(). HID core then tears down the driver without unwinding hidraw: the hidraw character device is not devres-managed, hdev->driver is cleared, and hid_device_remove() skips hid_hw_stop(). Opening the leftover /dev/hidraw node reaches hidraw_open() -> hid_hw_open() and writes into a freed transport object (typically under a spinlock). Confidentiality, integrity, and availability of kernel memory are all at risk (local UAF write; CVSS 7.8).

Why it matters to the business

A local user or process can crash hosts or, with further kernel-memory corruption, escalate to full system control. Impact is limited to machines that load the HID universal-pidff path (USB/HID force-feedback devices, including poorly described or emulated PID devices). There is no CISA KEV listing, no reported ransomware use, and no public exploit maturity as of 38 days after publication, but the local, low-complexity, high-impact profile still warrants timely kernel updates on workstations, kiosks, lab systems, and any fleet that accepts USB HID input.

How an attack unfolds

An attacker who already has local (low-privilege) access presents a HID device whose report descriptor uses a PID force-feedback usage page but has no input reports—via a physical dongle or a USB gadget/emulator. hidraw claims the device so hid_hw_start() succeeds; hid->inputs stays empty so hid_pidff_init_with_quirks() (or related FF setup) fails. The probe returns without stopping the device, leaving a live /dev/hidraw node bound to freed kernel objects. Opening that node triggers a use-after-free write in the transport open path. The same leftover node is reached on other post-start FF failures (missing output reports, allocation failure, pidff_init_fields/pidff_check_autocenter, unusable effect count, input_ff_create). There are no named threat actors or in-the-wild campaigns associated with this CVE.

How to fix it

Apply the upstream HID fix that stops the device on the post-start force-feedback failure path (dedicated error label calling hid_hw_stop(), matching hid-dr/hid-emsff). Upgrade to a Linux kernel build that includes that commit; distribution kernel packages that absorbed the HID: universal-pidff change are the practical remediation. Until patched, restrict who can attach USB HID devices (USB authorization, authorized-device policies, disabling unused HID/FF modules where operationally acceptable) and limit unprivileged access to hidraw nodes. Do not rely on unloading only the FF helper: the leftover hidraw registration is the core defect.

How to confirm the fix worked

Confirm the running kernel changelog or patch set includes the universal-pidff hid_hw_stop-on-FF-init-failure change (search for the new error label after hid_hw_start in drivers/hid). After upgrade, reproduce a PID-without-input-reports enumeration in a lab and verify the hidraw node is torn down on probe failure (no leftover /dev/hidraw, no KASAN/UAF on open). Inventory systems with hid-universal-pidff/hid-pidff loaded and world-accessible hidraw nodes. On unpatched kernels, treat any hidraw node that remains after a failed FF probe as evidence of exposure.

Typical attack path

1. Obtain local unprivileged code execution or interactive access on a Linux host that enumerates HID devices.
2. Attach or emulate a HID device with a PID usage page and no input reports (or another descriptor that makes FF init fail after hid_hw_start).
3. Wait for universal_pidff_probe to start the device, fail FF init, and leave /dev/hidraw registered against freed state.
4. Open the surviving hidraw node so hidraw_open/hid_hw_open writes into freed kernel memory.
5. Use the resulting kernel memory corruption for denial of service or local privilege escalation.

How to detect it

This issue has no public in-the-wild exploitation and no named actors; look for local artifacts rather than network C2. Review kernel logs (dmesg, journalctl -k, crash dumps, kdump/vmcore, KASAN/KFENCE reports) around HID probe time for universal-pidff/pidff init failures followed by hidraw opens. Correlate USB enumeration of PID/force-feedback devices that lack input reports with subsequent opens of /dev/hidraw* by unprivileged processes. On sanitizer or debug kernels, a UAF write attributed to hidraw_open -> hid_hw_open -> transport open is diagnostic. Audit udev/audit logs for unexpected hidraw node creation that outlives driver detach, and inspect whether hid-universal-pidff was bound then unbound without hid_hw_stop.

• universal-pidff
• hid_pidff_init_with_quirks
• pidff_init_fields
• pidff_check_autocenter
• hidraw_open
• hid_hw_open
• use-after-free write
• /dev/hidraw
• KASAN: use-after-free
• HID_CONNECT_DEFAULT
• input_ff_create

What your security team should do

• Patch Linux kernels that include HID universal-pidff as a priority for USB-accepting endpoints (developer workstations, kiosks, labs), even though this CVE is not in KEV.
• Until patched, tighten USB device authorization and hidraw permissions so unprivileged users cannot open leftover hidraw nodes.
• Hunt dmesg/journal and kernel sanitizer logs for hidraw_open/hid_hw_open use-after-free and failed universal-pidff/pidff probes.
• Track vendor/distro kernel advisories for the exact package version that carries this HID fix and verify fleet compliance.
• Treat unexpected USB gadget/HID PID devices as suspicious on multi-user hosts.