CVE-2025-40105

vfs: Don't leak disconnected dentries on umount

Published Oct 30, 2025 CVSS 3.1 · 7.8 High EPSS < 1% KEV · Not listed
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.

Remediation

No solution or workaround provided in the CVE record

Tracking

Sign in to view the affected projects.

Advisories

Source ID Title
Debian DLA Debian DLA DLA-4379-1 linux-6.1 security update
Debian DLA Debian DLA DLA-4404-1 linux security update
Debian DSA Debian DSA DSA-6053-1 linux security update
Ubuntu USN Ubuntu USN USN-8029-1 Linux kernel vulnerabilities
Ubuntu USN Ubuntu USN USN-8030-1 Linux kernel (GCP) vulnerabilities
Ubuntu USN Ubuntu USN USN-8033-1 Linux kernel vulnerabilities
Ubuntu USN Ubuntu USN USN-8033-2 Linux kernel vulnerabilities
Ubuntu USN Ubuntu USN USN-8033-3 Linux kernel (FIPS) vulnerabilities
Ubuntu USN Ubuntu USN USN-8034-1 Linux kernel (NVIDIA Tegra) vulnerabilities
Ubuntu USN Ubuntu USN USN-8033-4 Linux kernel (AWS) vulnerabilities
Ubuntu USN Ubuntu USN USN-8029-2 Linux kernel vulnerabilities
Ubuntu USN Ubuntu USN USN-8033-5 Linux kernel vulnerabilities
Ubuntu USN Ubuntu USN USN-8034-2 Linux kernel (NVIDIA Tegra IGX) vulnerabilities
Ubuntu USN Ubuntu USN USN-8048-1 Linux kernel (OEM) vulnerabilities
Ubuntu USN Ubuntu USN USN-8033-6 Linux kernel (NVIDIA) vulnerabilities
Ubuntu USN Ubuntu USN USN-8033-7 Linux kernel vulnerabilities
Ubuntu USN Ubuntu USN USN-8033-8 Linux kernel (Intel IoTG) vulnerabilities
Ubuntu USN Ubuntu USN USN-8029-3 Linux kernel (Azure) vulnerabilities
Ubuntu USN Ubuntu USN USN-8095-1 Linux kernel vulnerabilities
Ubuntu USN Ubuntu USN USN-8095-2 Linux kernel (FIPS) vulnerabilities
Ubuntu USN Ubuntu USN USN-8100-1 Linux kernel (NVIDIA) vulnerabilities
Ubuntu USN Ubuntu USN USN-8095-3 Linux kernel (Real-time) vulnerabilities
Ubuntu USN Ubuntu USN USN-8095-4 Linux kernel (AWS) vulnerabilities
Ubuntu USN Ubuntu USN USN-8125-1 Linux kernel (Azure) vulnerabilities
Ubuntu USN Ubuntu USN USN-8126-1 Linux kernel (Azure) vulnerabilities
Ubuntu USN Ubuntu USN USN-8095-5 Linux kernel (Raspberry Pi) vulnerabilities
Ubuntu USN Ubuntu USN USN-8141-1 Linux kernel (Raspberry Pi) vulnerabilities
Ubuntu USN Ubuntu USN USN-8163-1 Linux kernel (Azure FIPS) vulnerabilities
Ubuntu USN Ubuntu USN USN-8165-1 Linux kernel (Azure FIPS) vulnerabilities
Ubuntu USN Ubuntu USN USN-8163-2 Linux kernel (Azure) vulnerabilities
Ubuntu USN Ubuntu USN USN-8243-1 Linux kernel (Azure) vulnerabilities
Ubuntu USN Ubuntu USN USN-8261-1 Linux kernel (Xilinx) vulnerabilities
History
Type Values Removed Values Added
Metrics ssvc

{'options': {'Automatable': 'no', 'Exploitation': 'none', 'Technical Impact': 'total'}, 'version': '2.0.3'}

Type Values Removed Values Added
Metrics cvssV3_1

{'score': 5.5, 'vector': 'CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H'}

cvssV3_1

{'score': 7.8, 'vector': 'CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H'}

Type Values Removed Values Added
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Type Values Removed Values Added
References
Metrics threat_severity

None

cvssV3_1

{'score': 5.5, 'vector': 'CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H'}

threat_severity

Low

Type Values Removed Values Added
First Time appeared Linux
Linux linux Kernel
Vendors & Products Linux
Linux linux Kernel
Type Values Removed Values Added
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.
Title vfs: Don't leak disconnected dentries on umount
References
Weaknesses

No weakness.

Sources

Status
PUBLISHED
Assigner
Linux
Published
Updated
Nov 10, 2026, 12:37 PM
Reserved
Apr 16, 2025, 7:20 AM
Status
Deferred
Published
Oct 30, 2025, 10:15 AM
Modified
Nov 10, 2026, 1:17 PM
Severity
Low
Public date
Oct 30, 2025, 12:00 AM