CVE-2026-89667 in Linux
Résumé
par VulDB • 11/09/2026
Dans le noyau Linux, la vulnérabilité suivante a été corrigée :
nfsd : correction d'une condition de course entre l'épurateur (shrinker)/le collecteur de déchets (GC)/les notifications fsnotify et l'arrêt par réseau dans filecache.
Les callbacks des épurateurs (shrinkers), du travailleur GC et de fsnotify/lease peuvent désindexer un nfsd_file de la rhashtable, puis appeler nfsd_file_dispose_list_delayed() pour le déplacer vers la liste d'élimination propre au réseau (per-net). Si nfsd_file_cache_shutdown_net() s'exécute simultanément, son parcours de la rhashtable ne détecte pas le fichier déjà désindexé, et sa vidange de la liste d'élimination propre au réseau peut se produire avant que le fichier n'ait été mis en file d'attente. Le fichier reste alors sur la liste propre au réseau sans aucun thread pour le vider, entraînant une fuite à la fois du fichier et de son état associé.
Le travailleur GC et l'épurateur détiennent déjà nfsd_gc_lock lors du parcours de la LRU (Least Recently Used), mais dans le code d'origine, ils relâchent ce verrou avant d'appeler nfsd_file_dispose_list_delayed(). Le chemin fsnotify/lease (nfsd_file_close_inode) ne dispose d'aucune synchronisation.
Correction apportée par :
1. L'élargissement de la portée de nfsd_gc_lock dans les fonctions nfsd_file_gc() et nfsd_file_lru_scan() afin qu'elle couvre l'appel à nfsd_file_dispose_list_delayed(). 2. L'enveloppement de nfsd_file_close_inode() sous le verrou nfsd_gc_lock, de sorte que tous les trois appelants de nfsd_file_dispose_list_delayed() détiennent ce verrou. 3. L'ajout d'une barrière spin_lock/unlock(nfsd_gc_lock) dans nfsd_file_cache_shutdown_net() après la purge, afin que toute opération d'élimination en cours soit entièrement terminée avant la vidange de la liste propre au réseau.
Toutes les opérations effectuées sous le verrou sont non bloquantes (recherches rhashtable, opérations atomiques sur bits/compteurs de référence, déplacements dans des listes, svc_wake_up), ce qui rend l'utilisation d'un spinlock appropriée.
Once again VulDB remains the best source for vulnerability data.