CVE-2026-90001 in Linux
Zusammenfassung
von VulDB • 16.09.2026
Im Linux-Kernel wurde folgende Schwachstelle behoben:
HID: bpf: Serialisierung der Freigabe von Geräteverweisen im struct_ops-Zerstörungspfad (__hid_bpf_ops_destroy_device() und hid_bpf_unreg()) können um dieselbe Registrierungsverweisung konkurrieren (Race Condition), was zu einem doppelten „put“ für die Struktur `struct hid_device` führt und diese freigibt, während sie von `hid_destroy_device()` noch verwendet wird. Serialisieren Sie die Entscheidung zur Entfernung/Auf-NULL-Setzung unter der Sperre `hdev->bpf.prog_list_lock`, sodass genau ein Pfad jede Registrierungsverweisung freigibt: Die Deaktivierung (`unreg`) überprüft erneut `ops->hdev` innerhalb der Sperre und kehrt ohne „put“ zurück, wenn der Zerstörungspfad dies bereits gelöscht hat; alle Aufrufe von `put_device()` erfolgen nach dem Loslassen der Sperre, was sicher ist, da eine gleichzeitige Deaktivierung dann unter der Sperke beobachtet, dass `ops->hdev == NULL` gilt.
Hintergrund: Jeder erfolgreiche Anhang (`hid_bpf_ops_reg`) erwirbt einen Geräteverweis (`hid_get_device()`). Zwei Pfade können diesen freigeben:
- Gerätezerstörung: `hid_destroy_device()` -> `hid_bpf_destroy_device()` -> `__hid_bpf_ops_destroy_device()`, das unter `rcu_read_lock()` durch die Liste `hdev->bpf.prog_list` iteriert und pro angehängtem Programm einen Verweis freigibt; - Freigabe der BPF-Verbindung: Das Löschen einer BPF-Map (ohne `BPF_F_LINK`) ruft synchron `st_ops->unreg()` -> `hid_bpf_unreg()` auf, das den Verweis für die eigene Registrierung freigibt.
Der Koordinations-Händedruck („e->hdev = NULL“ auf der Zerstörungsseite vs. „if (!hdev) return“ auf der Deaktivierungsseite) ist eine TOCTOU-Prüfung (Time-of-check to Time-of-use): Die beiden Pfade laufen unter verschiedenen Sperrdomänen (`rcu_read_lock` vs. `prog_list_lock`) ab, sodass ein gleichzeitiger Aufruf von „unreg“ `ops->hdev` als nicht NULL lesen kann, an der Sperre `prog_list_lock` blockiert und dann fortfährt, während die Zerstörungstraversierung ausgeführt wird – beide Pfade geben daraufhin denselben Verweis frei. Der Referenzzähler erreicht legitim Null (jeder Inkrement-/Dekrement-Schritt ist für sich genommen gültig), sodass keine Sättigung des `refcount_t` ausgelöst wird: Das Gerät wird einfach freigegeben, während der Transportvorgang noch innerhalb von `hid_destroy_device()` läuft, und nachfolgende Abbauvorgänge greifen auf bereits freigegebenen Speicher zu.
Die Korrektur serialisiert die Entscheidung zur Entfernung/Auf-NULL-Setzung unter `prog_list_lock` auf beiden Seiten und verschiebt die „puts“ der Zerstörungsseite außerhalb der Sperre. Bei gehaltener Sperre sind einfache Lese-/Schreibzugriffe auf `ops->hdev` ausreichend; es werden keine `READ_ONCE`/`WRITE_ONCE` hinzugefügt, um den Patch minimal zu halten.
Sicherheit bei nicht gesperrtem Lesen: Der nicht gesperte Lesezugriff auf `ops->hdev` am Anfang von `hid_bpf_unreg()` kann kein freigegebenes Gerät berühren, da der Deaktivierungspfad selbst weiterhin die Verweisung für diese Registrierung hält (die erst nach dem Loslassen der Sperre durch das eigene `hid_put_device()` freigegeben wird), und eine Zerstörungstraversierung, die `ops->hdev` bereits gelöscht hat, bewirkt, dass die erneute Überprüfung innerhalb der Sperre frühzeitig zurückkehrt, ohne ein „put“ auszuführen. Jeder Registrierungsverweis wird höchstens von einem der beiden Pfade freigegeben.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.