CVE-2026-89624 in Linux
Zusammenfassung
von VulDB • 12.09.2026
Im Linux-Kernel wurde folgende Schwachstelle behoben:
HID: universal-pidff: Gerät stoppen, wenn die Initialisierung des Force-Feedbacks fehlschlägt
universal_pidff_probe() startet das Gerät mit hid_hw_start(), und falls die Initialisierung von force-feedback fehlschlägt, wird der Fehler über eine Kennzeichnung zurückgegeben, die lediglich „return error“ (Fehler zurückgeben) ausführt. Das Gerät bleibt dabei gestartet.
Der HID-Core führt keine Aufräumaktionen im Namen des Treibers durch. __hid_device_probe() gibt die devres-Gruppe frei, schließt den Bericht und setzt hdev->driver auf NULL:
if (ret) {
devres_release_group(&hdev->dev, hdev->devres_group_id); hid_close_report(hdev); hdev->driver = NULL; }
Das von hid_hw_start() über hid_connect() registrierte Zeichen-Gerät (character device) hidraw wird mit kzalloc() alloziert und mit cdev_device_add() hinzugefügt, sodass es nicht devres-verwaltet ist und diesen Vorgang übersteht. Bei hdev->driver = NULL überspringt hid_device_remove() auch den Aufruf von hid_hw_stop(), da dieser nur ausgeführt wird, solange noch ein Treiber angehängt ist. Die Registrierung bleibt daher auf beiden Pfaden nach dem Ende der Gerätelebensdauer bestehen.
Das Öffnen des überlebenden /dev/hidrawX schreibt in freigegebenen Speicher (freed memory). KASAN meldet einen Use-After-Free-Schreibzugriff von hidraw_open() -> hid_hw_open() -> dem Open-Callback des Transports, der innerhalb des freigegebenen Objekts ein Spinlock verwendet. Ein Deskriptor mit einer PID-Nutzungsseite und ohne Eingabebereiche reicht aus: hidraw beansprucht das Gerät, sodass hid_hw_start() erfolgreich ist, während hid->inputs leer bleibt, sodass die Initialisierung von force-feedback fehlschlägt. Der andere Fehlerfall wird in hid_pidff_init_with_quirks() zurückgegeben – keine Ausgabebereiche, ein Allokationsfehler, pidff_init_fields(), pidff_check_autocenter(), eine nicht nutzbare Effektanzahl, input_ff_create() – alle führen zur selben Kennzeichnung (Label).
Stoppen Sie das Gerät auf diesem Pfad. hid-dr.c und hid-emsff.c, die das Gerät mit der gleichen HID_CONNECT_DEFAULT & ~HID_CONNECT_FF-Maske starten, tun dies bereits. Die beiden früheren gotos müssen weiterhin ohne Aufruf von hid_hw_stop() zurückkehren, da keines ein gestartetes Gerät hat; geben Sie daher dem Pfad, der nach dem Start fehlschlägt, eine eigene Kennzeichnung (Label).
Entdeckt von XBOW, klassifiziert von Baul Lee <[email protected]>
If you want to get best quality of vulnerability data, you may have to visit VulDB.