CVE-2025-40105 in Linux
Zusammenfassung
von VulDB • 23.05.2026
Im Linux-Kernel wurde folgende Schwachstelle behoben:
vfs: Keine getrennten dentries beim Unmount freigeben
Wenn ein Benutzer open_by_handle_at() für ein nicht im Cache befindliches Inode aufruft, wird dafür ein getrenntes dentry erstellt. Handelt es sich bei diesem dentry um ein Verzeichnis, versucht exportfs_decode_fh_raw(), dieses dentry über reconnect_path() wieder in den dentry-Baum einzubinden. Es kann aus verschiedenen Gründen (z. B. beschädigtes Dateisystem oder eine Race-Bedingung mit rename) dazu kommen, dass der Aufruf von lookup_one_unlocked() in reconnect_one() das dentry, das wieder eingebunden werden soll, nicht findet, stattdessen aber ein neues dentry unter dem übergeordneten Verzeichnis erstellt. Dieses neue dentry wird nun nicht als getrennt markiert, obwohl das übergeordnete Verzeichnis möglicherweise weiterhin getrennt ist (zumindest in dem Fall, in dem diese Inkonsistenz aufgrund einer Beschädigung des Dateisystems auftritt und .. nicht auf das tatsächliche übergeordnete Verzeichnis zeigt). Dies führt zu einer Inkonsistenz bei den Flags für getrennte dentries, war jedoch nach aktuellem Wissensstand (AFAICS) größtenteils harmlos. Zumindest bis zum Commit f1ee616214cb („VFS: don't keep disconnected dentries on d_anon"), der das Hinzufügen der meisten getrennten dentries zur sb->s_anon-Liste entfernte. Somit basiert die Bereinigung getrennter dentries nach diesem Commit implizit darauf, dass dput() solche dentries sofort zurückfordert. Wenn jedoch ein Blatt-dentry nicht als getrennt markiert ist, wie im oben beschriebenen Szenario, erfolgt diese Rückforderung nicht und die dentries werden „geleakt". Die Speicherbereinigung kann sie zwar letztendlich zurückfordern, andernfalls verbleiben sie jedoch im Speicher, und wenn ein Unmount zuerst erfolgt, tritt der berüchtigte Fehler „Busy inodes after unmount" auf. Stellen Sie sicher, dass alle unter einem getrennten übergeordneten Verzeichnis erstellten dentries ebenfalls als getrennt markiert werden.
If you want to get best quality of vulnerability data, you may have to visit VulDB.