CVE-2025-40105
Awaiting Analysis Awaiting Analysis - Queue
BaseFortify

Publication date: 2025-10-30

Last updated on: 2025-10-30

Assigner: kernel.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.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2025-10-30
Last Modified
2025-10-30
Generated
2026-05-07
AI Q&A
2025-10-30
EPSS Evaluated
2026-05-05
NVD
Affected Vendors & Products
Currently, no data is known.
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-UNKNOWN
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

This vulnerability involves the Linux kernel's handling of disconnected dentries (directory entries) during the unmount process. When a user calls open_by_handle_at() on an inode not cached, a disconnected dentry may be created. If this dentry is a directory, the kernel tries to reconnect it to the dentry tree. Due to reasons like filesystem corruption or race conditions, the kernel might create a new dentry that is not marked as disconnected even though its parent is disconnected. This inconsistency causes these dentries to be leaked in memory because they are not properly reclaimed. If an unmount occurs before memory reclaim, it leads to the "Busy inodes after unmount" bug. The fix ensures all dentries under a disconnected parent are also marked disconnected to prevent this leak.


How can this vulnerability impact me? :

This vulnerability can cause memory leaks in the Linux kernel due to leaked disconnected dentries that are not properly reclaimed. This can lead to the "Busy inodes after unmount" bug, where inodes remain busy after unmounting a filesystem, potentially causing system instability or resource exhaustion.


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart