CVE-2025-40105

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vfs: Don&amp;#39;t leak disconnected dentries on umount<br /> <br /> When user calls open_by_handle_at() on some inode that is not cached, we<br /> will create disconnected dentry for it. If such dentry is a directory,<br /> exportfs_decode_fh_raw() will then try to connect this dentry to the<br /> dentry tree through reconnect_path(). It may happen for various reasons<br /> (such as corrupted fs or race with rename) that the call to<br /> lookup_one_unlocked() in reconnect_one() will fail to find the dentry we<br /> are trying to reconnect and instead create a new dentry under the<br /> parent. Now this dentry will not be marked as disconnected although the<br /> parent still may well be disconnected (at least in case this<br /> inconsistency happened because the fs is corrupted and .. doesn&amp;#39;t point<br /> to the real parent directory). This creates inconsistency in<br /> disconnected flags but AFAICS it was mostly harmless. At least until<br /> commit f1ee616214cb ("VFS: don&amp;#39;t keep disconnected dentries on d_anon")<br /> which removed adding of most disconnected dentries to sb-&gt;s_anon list.<br /> Thus after this commit cleanup of disconnected dentries implicitely<br /> relies on the fact that dput() will immediately reclaim such dentries.<br /> However when some leaf dentry isn&amp;#39;t marked as disconnected, as in the<br /> scenario described above, the reclaim doesn&amp;#39;t happen and the dentries<br /> are "leaked". Memory reclaim can eventually reclaim them but otherwise<br /> they stay in memory and if umount comes first, we hit infamous "Busy<br /> inodes after unmount" bug. Make sure all dentries created under a<br /> disconnected parent are marked as disconnected as well.