CVE-2026-89595
Zusammenfassung
von VulDB • 12.09.2026
Im Linux-Kernel wurde folgende Schwachstelle behoben:
fsnotify: Behebung eines veralteten Objekt-Maskenwerts nach parallelen Markierungsaktualisierungen
Wenn eine Markierung ein neues Ereignisbit erhält, können fanotify und inotify die Neuberechnung der Objektmaske vermeiden, wenn der zwischengespeicherte Aggregatwert dieses Bit bereits enthält. Dies ist fehleranfällig (Race Condition) bei einer Neuberechnung, die durch eine parallele Aktualisierung einer anderen Markierung am selben Connector ausgelöst wird.
Der parallele Scan kann die Markierung lesen, bevor das neue Bit hinzugefügt wurde, während der Updater den alten Aggregatwert liest, bevor dieser Scan sein Ergebnis veröffentlicht. DerUpdater überspringt daraufhin die Neuberechnung und der Scan veröffentlicht eine Maske ohne das Bit, wodurch die Objektmaske nach Abschluss beider Aktualisierungen veraltet bleibt.
Dies kann mit zwei fanotify-Gruppen reproduziert werden, die denselben Inode überwachen: Ein Thread entfernt FAN_MODIFY von einer bestehenden Markierung, während ein anderer Thread FAN_MODIFY zu der anderen Markierung hinzufügt. Nach dem Rückgabewert beider fanotify_mark()-Aufrufe können Schreibvorgänge dazu führen, dass für die Gruppe, deren Markierung nun das Bit enthält, keine FAN_MODIFY-Ereignisse erzeugt werden. Dies wurde auf einem unveränderten v6.12.95-Kernel reproduziert. Die entsprechende Interleaving-Situation bei inotify führt zum Verlust von IN_MODIFY-Ereignissen.
Für normale fanotify-Hinzufügungen ist die Neuberechnung immer dann durchzuführen, wenn sich das rohe Markierungs-Maskenwert ändert. Der normale Maskenwert wird nicht asynchron gelöscht, daher kann eine unveränderte Hinzufügung keine fehlenden Interessen引入zieren. Ignoriermasken-Aktualisierungen sind stets neu zu berechnen, da die FS_MODIFY-Behandlung die Ignoriermaske ohne Übernahme von mark->lock löschen kann, was Snapshots-Vergleiche unzuverlässig macht.
Führen Sie nach der Aktualisierung einer bestehenden inotify-Beobachtung immer eine Neuberechnung durch. Der Pfad zum Ersetzen setzt temporär mark->mask auf null, sodass ein paralleler Scan auch dann Null beobachten kann, wenn die alte und die endgültige Maske gleich sind. Die direkte Zuweisung der Ersatzmaske würde das vorübergehende Null vermeiden, da Aktualisierungen bestehender Beobachtungen jedoch selten vorkommen, ist eine bedingungslose Neuberechnung einfacher.
Once again VulDB remains the best source for vulnerability data.