CVE-2025-40105 (CNNVD-202510-4246)

UNKNOWN
中文标题:
Linux kernel 安全漏洞
英文标题:
vfs: Don't leak disconnected dentries on umount
CVSS分数: N/A
发布时间: 2025-10-30 09:48:09
漏洞类型: 其他
状态: PUBLISHED
数据质量分数: 0.30
数据版本: v3
漏洞描述
中文描述:

Linux kernel是美国Linux基金会的开源操作系统Linux所使用的内核。 Linux kernel存在安全漏洞,该漏洞源于未正确处理断开连接的dentry,可能导致内存泄漏。

英文描述:

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.

CWE类型:
(暂无数据)
标签:
(暂无数据)
受影响产品
厂商 产品 版本 版本范围 平台 CPE
Linux Linux - < b5abafd0aa8d7bcb935c8f91e4cfc2f2820759e4 - cpe:2.3:a:linux:linux:*:*:*:*:*:*:*:*
Linux Linux 4.16 - - cpe:2.3:a:linux:linux:4.16:*:*:*:*:*:*:*
解决方案
中文解决方案:
(暂无数据)
英文解决方案:
(暂无数据)
临时解决方案:
(暂无数据)
参考链接
无标题 OTHER
cve.org
访问
无标题 OTHER
cve.org
访问
无标题 OTHER
cve.org
访问
无标题 OTHER
cve.org
访问
无标题 OTHER
cve.org
访问
无标题 OTHER
cve.org
访问
无标题 OTHER
cve.org
访问
无标题 OTHER
cve.org
访问
CVSS评分详情
暂无CVSS评分信息
时间信息
发布时间:
2025-10-30 09:48:09
修改时间:
2025-10-30 09:48:09
创建时间:
2025-11-11 15:40:30
更新时间:
2025-11-11 16:00:20
利用信息
暂无可利用代码信息
数据源详情
数据源 记录ID 版本 提取时间
CVE cve_CVE-2025-40105 2025-11-11 15:23:20 2025-11-11 07:40:30
NVD nvd_CVE-2025-40105 2025-11-11 15:01:07 2025-11-11 07:48:19
CNNVD cnnvd_CNNVD-202510-4246 2025-11-11 15:12:59 2025-11-11 08:00:20
版本与语言
当前版本: v3
主要语言: EN
支持语言:
EN ZH
安全公告
暂无安全公告信息
变更历史
v3 CNNVD
2025-11-11 16:00:20
vulnerability_type: 未提取 → 其他; severity: SeverityLevel.MEDIUM → SeverityLevel.UNKNOWN; cvss_score: 未提取 → 0.0; cnnvd_id: 未提取 → CNNVD-202510-4246; data_sources: ['cve', 'nvd'] → ['cnnvd', 'cve', 'nvd']
查看详细变更
  • vulnerability_type: 未提取 -> 其他
  • severity: SeverityLevel.MEDIUM -> SeverityLevel.UNKNOWN
  • cvss_score: 未提取 -> 0.0
  • cnnvd_id: 未提取 -> CNNVD-202510-4246
  • data_sources: ['cve', 'nvd'] -> ['cnnvd', 'cve', 'nvd']
v2 NVD
2025-11-11 15:48:19
affected_products_count: 9 → 2; data_sources: ['cve'] → ['cve', 'nvd']
查看详细变更
  • affected_products_count: 9 -> 2
  • data_sources: ['cve'] -> ['cve', 'nvd']