{"id":21546,"date":"2026-09-12T04:31:20","date_gmt":"2026-09-11T20:31:20","guid":{"rendered":"https:\/\/www.54iter.cn\/?vuln=cve-2026-89624"},"modified":"2026-09-12T04:31:20","modified_gmt":"2026-09-11T20:31:20","slug":"cve-2026-89624","status":"publish","type":"vuln","link":"https:\/\/www.54iter.cn\/?vuln=cve-2026-89624","title":{"rendered":"CVE-2026-89624 &#8211; In the Linux kernel, the following vulnerability has been resolved:\n\nHID: universal-pidff:"},"content":{"rendered":"<p>In the Linux kernel, the following vulnerability has been resolved:<\/p>\n<p>HID: universal-pidff: stop the device when force-feedback init fails<\/p>\n<p>universal_pidff_probe() starts the device with hid_hw_start() and then, if<br \/>\nforce-feedback initialisation fails, returns the error through a label that<br \/>\nonly does &#8220;return error&#8221;.  The device is left started.<\/p>\n<p>The HID core does not unwind on the driver&#8217;s behalf.  __hid_device_probe()<br \/>\nreleases the devres group, closes the report and clears hdev-&gt;driver:<\/p>\n<p>\tif (ret) {<br \/>\n\t\tdevres_release_group(&amp;hdev-&gt;dev, hdev-&gt;devres_group_id);<br \/>\n\t\thid_close_report(hdev);<br \/>\n\t\thdev-&gt;driver = NULL;<br \/>\n\t}<\/p>\n<p>The hidraw character device that hid_hw_start() registered through<br \/>\nhid_connect() is allocated with kzalloc() and added with cdev_device_add(),<br \/>\nso it is not devres-managed and survives that.  With hdev-&gt;driver NULL,<br \/>\nhid_device_remove() skips hid_hw_stop() as well, because it only unwinds<br \/>\nwhile a driver is still attached.  The registration therefore outlives the<br \/>\ndevice on both paths.<\/p>\n<p>Opening the surviving \/dev\/hidrawX writes into freed memory.  KASAN reports<br \/>\na use-after-free write from hidraw_open() -&gt; hid_hw_open() -&gt; the<br \/>\ntransport&#8217;s open callback, which takes a spinlock inside the freed object.<br \/>\nA descriptor that carries a PID usage page and no input reports is enough:<br \/>\nhidraw claims the device so hid_hw_start() succeeds, while hid-&gt;inputs<br \/>\nstays empty so force-feedback init fails.  The other failure returns in<br \/>\nhid_pidff_init_with_quirks() &#8211; no output reports, an allocation failure,<br \/>\npidff_init_fields(), pidff_check_autocenter(), an unusable effect count,<br \/>\ninput_ff_create() &#8211; all reach the same label.<\/p>\n<p>Stop the device on that path.  hid-dr.c and hid-emsff.c, which start the<br \/>\ndevice with the same HID_CONNECT_DEFAULT &amp; ~HID_CONNECT_FF mask, already do<br \/>\nthis.  The two earlier gotos must keep returning without hid_hw_stop(),<br \/>\nsince neither has a started device, so give the path that fails after the<br \/>\nstart its own label.<\/p>\n<p>Discovered by XBOW, triaged by Baul Lee <\/p>\n","protected":false},"excerpt":{"rendered":"<p>In the Linux kernel, the following vulnerability has been resolved:<\/p>\n<p>HID: universal-pidff: stop the device when force-feedback init fails<\/p>\n<p>universal_pidff_probe() starts the device with hid_hw_start()<\/p>\n","protected":false},"template":"","meta":[],"categories":[],"tags":[],"class_list":["post-21546","vuln","type-vuln","status-publish","hentry"],"_links":{"self":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/vuln\/21546","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/vuln"}],"about":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/types\/vuln"}],"wp:attachment":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=21546"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=21546"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=21546"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}