Message-ID: <2025103018-CVE-2025-40105-a635@gregkh>
Date: Thu, 30 Oct 2025 10:48:32 +0100
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: linux-cve-announce@...r.kernel.org
Cc: Greg Kroah-Hartman <gregkh@...nel.org>
Subject: CVE-2025-40105: vfs: Don't leak disconnected dentries on umount

From: Greg Kroah-Hartman <gregkh@...nel.org>

Description
===========

In the Linux kernel, the following vulnerability has been resolved:

vfs: Don't leak disconnected dentries on umount

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

The Linux kernel CVE team has assigned CVE-2025-40105 to this issue.


Affected and fixed versions
===========================

	Issue introduced in 4.16 with commit f1ee616214cb22410e939d963bbb2349c2570f02 and fixed in 5.4.301 with commit b5abafd0aa8d7bcb935c8f91e4cfc2f2820759e4
	Issue introduced in 4.16 with commit f1ee616214cb22410e939d963bbb2349c2570f02 and fixed in 5.10.246 with commit 20863bb7fbb016379f8227122edfabc5c799bc79
	Issue introduced in 4.16 with commit f1ee616214cb22410e939d963bbb2349c2570f02 and fixed in 5.15.196 with commit 8004d4b8cbf1bd68a23c160d57287e177c82cc69
	Issue introduced in 4.16 with commit f1ee616214cb22410e939d963bbb2349c2570f02 and fixed in 6.1.158 with commit 7e0c8aaf4e28918abded547a5147c7d52c4af7d2
	Issue introduced in 4.16 with commit f1ee616214cb22410e939d963bbb2349c2570f02 and fixed in 6.6.114 with commit cebfbf40056a4d858b2a3ca59a69936d599bd209
	Issue introduced in 4.16 with commit f1ee616214cb22410e939d963bbb2349c2570f02 and fixed in 6.12.55 with commit 620f3b0ede9c5cb4976cd0457d0b04ad551e5d6b
	Issue introduced in 4.16 with commit f1ee616214cb22410e939d963bbb2349c2570f02 and fixed in 6.17.5 with commit eadc49999fa994d6fbd70c332bd5d5051cc42261
	Issue introduced in 4.16 with commit f1ee616214cb22410e939d963bbb2349c2570f02 and fixed in 6.18-rc2 with commit 56094ad3eaa21e6621396cc33811d8f72847a834

Please see https://www.kernel.org for a full list of currently supported
kernel versions by the kernel community.

Unaffected versions might change over time as fixes are backported to
older supported kernel versions.  The official CVE entry at
	https://cve.org/CVERecord/?id=CVE-2025-40105
will be updated if fixes are backported, please check that for the most
up to date information about this issue.


Affected files
==============

The file(s) affected by this issue are:
	fs/dcache.c


Mitigation
==========

The Linux kernel CVE team recommends that you update to the latest
stable kernel version for this, and many other bugfixes.  Individual
changes are never tested alone, but rather are part of a larger kernel
release.  Cherry-picking individual commits is not recommended or
supported by the Linux kernel community at all.  If however, updating to
the latest release is impossible, the individual changes to resolve this
issue can be found at these commits:
	https://git.kernel.org/stable/c/b5abafd0aa8d7bcb935c8f91e4cfc2f2820759e4
	https://git.kernel.org/stable/c/20863bb7fbb016379f8227122edfabc5c799bc79
	https://git.kernel.org/stable/c/8004d4b8cbf1bd68a23c160d57287e177c82cc69
	https://git.kernel.org/stable/c/7e0c8aaf4e28918abded547a5147c7d52c4af7d2
	https://git.kernel.org/stable/c/cebfbf40056a4d858b2a3ca59a69936d599bd209
	https://git.kernel.org/stable/c/620f3b0ede9c5cb4976cd0457d0b04ad551e5d6b
	https://git.kernel.org/stable/c/eadc49999fa994d6fbd70c332bd5d5051cc42261
	https://git.kernel.org/stable/c/56094ad3eaa21e6621396cc33811d8f72847a834

Powered by blists - more mailing lists