CVE-2026-89624

In the Linux kernel, the following vulnerability has been resolved:

HID: universal-pidff: stop the device when force-feedback init fails

universal pidff probe() starts the device with hid hw start() and then, if force-feedback initialisation fails, returns the error through a label that only does "return error". The device is left started.

The HID core does not unwind on the driver's behalf. hid device probe() releases the devres group, closes the report and clears hdev->driver:

if (ret) {
	devres release group(&hdev->dev, hdev->devres group id);
	hid close report(hdev);
	hdev->driver = NULL;
}

The hidraw character device that hid hw start() registered through hid connect() is allocated with kzalloc() and added with cdev device add(), so it is not devres-managed and survives that. With hdev->driver NULL, hid device remove() skips hid hw stop() as well, because it only unwinds while a driver is still attached. The registration therefore outlives the device on both paths.

Opening the surviving /dev/hidrawX writes into freed memory. KASAN reports a use-after-free write from hidraw open() -> hid hw open() -> the transport's open callback, which takes a spinlock inside the freed object. A descriptor that carries a PID usage page and no input reports is enough: hidraw claims the device so hid hw start() succeeds, while hid->inputs stays empty so force-feedback init fails. The other failure returns in hid pidff init with quirks() - no output reports, an allocation failure, pidff init fields(), pidff check autocenter(), an unusable effect count, input ff create() - all reach the same label.

Stop the device on that path. hid-dr.c and hid-emsff.c, which start the device with the same HID CONNECT DEFAULT & ~HID CONNECT FF mask, already do this. The two earlier gotos must keep returning without hid hw stop(), since neither has a started device, so give the path that fails after the start its own label.

Discovered by XBOW, triaged by Baul Lee baul.lee@xbow.com