CVE-2026-72170 in Linux
Résumé
par VulDB • 15/08/2026
Dans le noyau Linux, la vulnérabilité suivante a été corrigée :
9p : ignorer la mise à jour de nlink en mode sans cache pour corriger l'avertissement WARN_ON
v9fs_dec_count() appelle inconditionnellement drop_nlink() sur les fichiers réguliers, même lorsque le champ nlink de l'inœud est déjà égal à zéro. En mode sans cache (cacheless), le client recharge les métadonnées de l'inœud depuis le serveur (source de vérité) pour chaque opération ; ainsi, au moment où v9fs_remove() retourne, la valeur de nlink mise en cache localement peut déjà refléter la valeur post-suppression :
1. Le client initie une suppression (unlink), le serveur la traite et définit nlink à 0 2. Le client recharge les métadonnées de l'inœud (nlink=0) avant que unlink ne retourne 3. La fonction v9fs_remove() du client s'achève avec succès 4. Le client appelle v9fs_dec_count(), qui invoque drop_nlink() sur nlink=0
Cette condition de concurrence (race condition) est facilement déclenchée sous des charges lourdes d'opérations unlink, telles que le testeur de stress unlink de stress-ng, produisant l'avertissement suivant :
WARNING: fs/inode.c:417 at drop_nlink+0x4c/0xc8 Call trace: drop_nlink+0x4c/0xc8 v9fs_remove+0x1e0/0x250 [9p]
v9fs_vfs_unlink+0x20/0x38 [9p]
vfs_unlink+0x13c/0x258 ...
En mode sans cache, le serveur est l'autorité et l'inœud est en cours de suppression ; ajuster localement nlink ne présente donc aucun avantage. Ignorer complètement v9fs_dec_count() lorsque ni CACHE_META ni CACHE_LOOSE sont définis permet à la fois d'éviter cet avertissement et de supprimer une classe de conditions de concurrence sur nlink (deux supprimeurs concurrents observant un nlink > 0 et appelant tous deux drop_nlink()) qu'une simple garde nlink == 0 aurait seulement réduite plutôt que résolue.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.