CVE-2026-93189

Zusammenfassung

Im Linux-Kernel wurde die folgende Schwachstelle behoben: HID: core: quiesce input in hid_hw_stop() to prevent use-after-free Die Probe-Funktion eines Treibers ruft hid_device_io_start() auf, um die Eingabezustellung zu aktivieren, schlägt dann bei einem späteren Initialisierungsschritt fehl und wird über hid_hw_stop() zurückgerollt. Beim Zurückrollen wird struct hidraw über hidraw_disconnect() freigegeben, während noch laufende HID-Berichte auf einer anderen CPU ausgeführt werden könnten und über hidraw_report_event() auf das freigegebene Objekt zugreifen. syzbot meldet den daraus resultierenden Use-after-free für den corsair-psu-HID-Treiber. Edward Adam Davis hat einen treiberspezifischen Fix für corsair-psu veröffentlicht, der einen expliziten hid_device_io_stop()-Aufruf vor hid_hw_stop() im Fehlerpfad der Probe-Funktion hinzufügt ("hwmon: prevent packets from going to driver for probe", 2026-04-28). Eine Prüfung des Trees zeigt, dass 15 Treiber hid_device_io_start() aufrufen; 7 rufen auch hid_device_io_stop() auf und 8 nicht: Treiber, die hid_device_io_start() ohne ein passendes hid_device_io_stop() vor hid_hw_stop() aufrufen: drivers/hwmon/corsair-psu.c (Fix von Edward veröffentlicht) drivers/hwmon/corsair-cpro.c drivers/hwmon/nzxt-kraken3.c drivers/hwmon/nzxt-smart2.c drivers/hwmon/gigabyte_waterforce.c drivers/hid/hid-logitech-dj.c drivers/hid/hid-nintendo.c drivers/hid/hid-mcp2221.c Etwa die Hälfte aller Aufrufer der API ist betroffen. Zentralisieren Sie die Quiesce in hid_hw_stop(), damit Aufrufer sich nicht an den passenden Stop erinnern müssen: Wenn ein Treiber hdev->io_started beim Eintritt auf true gelassen hat, rufen Sie hid_device_io_stop() vor hid_disconnect() auf. Für die 7 Treiber, die hid_device_io_stop() bereits korrekt aufrufen, ist hdev->io_started beim Eintritt false, die Prüfung greift kurz und das Verhalten bleibt unverändert. Kein Fixes:-Tag, da die betroffenen Treiber ihre hid_device_io_start()-Aufrufe unabhängig über Jahre hinweg erhalten haben; der Fehler ist eine klassenweite API-Fehlanwendung und keine Regression durch einen einzelnen Commit.

Quellen

• pixel-ksu-root