CVE-2026-89624

The Linux kernel's HID universal-pidff force-feedback driver calls hid_hw_start() but fails to stop the device when force-feedback initialization subsequently fails, leaving an orphaned /dev/hidrawX character device registered after the underlying device structures are freed. The flaw is triggered by a malicious or malformed HID device whose descriptor carries a PID (Physical Interface Device) usage page but no input reports, which lets hidraw claim the device (so hid_hw_start succeeds) while force-feedback init fails and the error path returns without cleanup; other ff-init failures (no output reports, allocation failure, bad effect count) reach the same path. Opening the surviving /dev/hidrawX then performs a use-after-free write from hidraw_open() -> hid_hw_open() -> the transport's open callback, which takes a spinlock inside freed memory, giving a local attacker potential kernel memory corruption with high confidentiality, integrity, and availability impact (CVSS 7.8, local vector, low privileges required). In practice, exploitation requires a crafted USB force-feedback peripheral to be connected or local access to the resulting hidraw node, so systems using PID force-feedback hardware (e.g., sim-racing wheels and force-feedback joysticks) are the main concern. The flaw was disclosed responsibly (found by XBOW), no public proof-of-concept exists, it is not in CISA's KEV, and no exploitation is known.

What to do: Apply distribution kernel updates as soon as a build containing the fix (which calls hid_hw_stop() on the force-feedback init failure path) is available. In the meantime, restrict physical USB/HID peripheral access on sensitive hosts, consider blacklisting the universal-pidff driver (or disabling HID force feedback in kernel config) on machines that don't need force-feedback input devices, and tighten permissions on /dev/hidraw* nodes. Audit endpoints for unexpected or unknown HID/hidraw devices, especially on multi-user or publicly accessible Linux systems.