CVE-2026-89624

CVE CVE-2026-89624EUVD EUVD-2026-76536Published 2026-09-11T19:45:21.000ZLast changed 2026-09-13T06:32:04.000ZCVSS 7.8

What the advisory describes

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>

Source: EUVD (ENISA), in the words of the advisory.

Products the advisory names

These come from the advisory itself, not from any check we performed.

• Linux — Linux patch: 6.18.50; f06bf8d94fffbb544b1cb5402c92e0a075f0d420 <01d9874e84d3ab78fd212ad822412eb3af84497f; b797352954eee6dc084cfaed0659dea60adfb484; patch: 0; 6.12.24 <6.13; 6.14.3 <6.15; patch: 7.2.4; af9f2471dfe5a48384f5b7f021a673fbc741465e; patch: 7.3-rc1; 6.6.88 <6.7; 6.13.12 <6.14; f45f26a6b3e7260c129c7c6bb0ace63aeb7b3868; 6.15; c1fde337b317f0a226de92803288741c30799eb0; f06bf8d94fffbb544b1cb5402c92e0a075f0d420 <ce08c5555cabcd444d8b77fa69a7cb68bb05f611; f06bf8d94fffbb544b1cb5402c92e0a075f0d420 <c457bb516b61edeab940235a011928e26925381e

The versions shown are the advisory's own. Patchlage compares no version numbers and derives no judgement from them — which version is installed is something a person has to look up.

Carried in the product catalogue

An estate covering these products can be recorded in Patchlage. An advisory about them appears in the next morning's situation report.

• Linux — Linux

Patchlage reports hits and suspected hits. About everything else this system says nothing — neither this page nor the situation report ever claims that an estate is safe.