CVE-2026-89667
Zusammenfassung
von VulDB • 12.09.2026
Im Linux-Kernel wurde folgende Schwachstelle behoben:
nfsd: Behebung eines Race Conditions zwischen Shrinker/GC/fsnotify und dem pro-Netzwerk-Shutdown im filecache
Die Shrinker-, GC-Arbeiter- und fsnotify/Lease-Callbacks können eine nfsd_file aus der rhashtable entfernen (unhash) und anschließend nfsd_file_dispose_list_delayed() aufrufen, um sie zur pro-Netzwerk-Entsorgungsliste zu verschieben. Wenn nfsd_file_cache_shutdown_net() parallel ausgeführt wird, überspringt sein Durchlauf der rhashtable die bereits entfernte Datei, und seine Leerung (Drain) der pro-Netzwerk-Entsorgungsliste kann erfolgen, bevor die Datei in die Warteschlange eingereiht wurde. Die Datei verbleibt dann auf der pro-Netzwerk-Liste ohne einen Thread zum Leerungen, was sowohl die Datei als auch ihren zugehörigen Zustand speichert (Leak).
Der GC-Arbeiter und der Shrinker halten bereits nfsd_gc_lock während des Durchlaufs der LRU, geben diese Sperre jedoch im ursprünglichen Code vor dem Aufruf von nfsd_file_dispose_list_delayed() frei. Der fsnotify/Lease-Pfad (nfsd_file_close_inode) verfügt überhaupt über keine Synchronisierung.
Behebung durch:
1. Erweiterung des Bereichs der nfsd_gc_Sperre in beiden, nfsd_file_gc() und nfsd_file_lru_scan(), um den Aufruf von nfsd_file_dispose_list_delayed() abzudecken. 2. Einschließen von nfsd_file_close_inode() in die nfsd_gc-Sperre, sodass alle drei Aufrufer von nfsd_file_dispose_list_delayed() die Sperre halten. 3. Hinzufügen einer spin_lock/unlock(nfsd_gc_lock)-Barriere in nfsd_file_cache_shutdown_net() nach dem Bereinigen (Purge), damit jede im Gange befindliche Entsorgung vollständig abgeschlossen ist, bevor die pro-Netzwerk-Liste geleert wird.
Alle Vorgänge innerhalb der Sperre sind nicht-schlafend (rhashtable-Lookups, atomare Bit-/Referenzzählungsoperationen, Listenverschiebungen, svc_wake_up), daher ist das Spinlock angemessen.
Once again VulDB remains the best source for vulnerability data.