CVE-2025-40007 (CNNVD-202510-2615)
中文标题:
Linux kernel 安全漏洞
英文标题:
netfs: fix reference leak
漏洞描述
中文描述:
Linux kernel是美国Linux基金会的开源操作系统Linux所使用的内核。 Linux kernel存在安全漏洞,该漏洞源于netfs_alloc_request函数中引用计数初始化不当,可能导致引用泄漏和死锁。
英文描述:
In the Linux kernel, the following vulnerability has been resolved: netfs: fix reference leak Commit 20d72b00ca81 ("netfs: Fix the request's work item to not require a ref") modified netfs_alloc_request() to initialize the reference counter to 2 instead of 1. The rationale was that the requet's "work" would release the second reference after completion (via netfs_{read,write}_collection_worker()). That works most of the time if all goes well. However, it leaks this additional reference if the request is released before the I/O operation has been submitted: the error code path only decrements the reference counter once and the work item will never be queued because there will never be a completion. This has caused outages of our whole server cluster today because tasks were blocked in netfs_wait_for_outstanding_io(), leading to deadlocks in Ceph (another bug that I will address soon in another patch). This was caused by a netfs_pgpriv2_begin_copy_to_cache() call which failed in fscache_begin_write_operation(). The leaked netfs_io_request was never completed, leaving `netfs_inode.io_count` with a positive value forever. All of this is super-fragile code. Finding out which code paths will lead to an eventual completion and which do not is hard to see: - Some functions like netfs_create_write_req() allocate a request, but will never submit any I/O. - netfs_unbuffered_read_iter_locked() calls netfs_unbuffered_read() and then netfs_put_request(); however, netfs_unbuffered_read() can also fail early before submitting the I/O request, therefore another netfs_put_request() call must be added there. A rule of thumb is that functions that return a `netfs_io_request` do not submit I/O, and all of their callers must be checked. For my taste, the whole netfs code needs an overhaul to make reference counting easier to understand and less fragile & obscure. But to fix this bug here and now and produce a patch that is adequate for a stable backport, I tried a minimal approach that quickly frees the request object upon early failure. I decided against adding a second netfs_put_request() each time because that would cause code duplication which obscures the code further. Instead, I added the function netfs_put_failed_request() which frees such a failed request synchronously under the assumption that the reference count is exactly 2 (as initially set by netfs_alloc_request() and never touched), verified by a WARN_ON_ONCE(). It then deinitializes the request object (without going through the "cleanup_work" indirection) and frees the allocation (with RCU protection to protect against concurrent access by netfs_requests_seq_start()). All code paths that fail early have been changed to call netfs_put_failed_request() instead of netfs_put_request(). Additionally, I have added a netfs_put_request() call to netfs_unbuffered_read() as explained above because the netfs_put_failed_request() approach does not work there.
CWE类型:
标签:
受影响产品
| 厂商 | 产品 | 版本 | 版本范围 | 平台 | CPE |
|---|---|---|---|---|---|
| Linux | Linux | 1a8360c2eed3b292ed654c2ac61b09de4a80e298 | - | - |
cpe:2.3:a:linux:linux:1a8360c2eed3b292ed654c2ac61b09de4a80e298:*:*:*:*:*:*:*
|
| Linux | Linux | 6.16 | - | - |
cpe:2.3:a:linux:linux:6.16:*:*:*:*:*:*:*
|
解决方案
中文解决方案:
英文解决方案:
临时解决方案:
CVSS评分详情
时间信息
利用信息
数据源详情
| 数据源 | 记录ID | 版本 | 提取时间 |
|---|---|---|---|
| CVE | cve_CVE-2025-40007 |
2025-11-11 15:23:20 | 2025-11-11 07:40:29 |
| NVD | nvd_CVE-2025-40007 |
2025-11-11 15:01:06 | 2025-11-11 07:48:18 |
| CNNVD | cnnvd_CNNVD-202510-2615 |
2025-11-11 15:13:00 | 2025-11-11 08:00:18 |
版本与语言
安全公告
变更历史
查看详细变更
- vulnerability_type: 未提取 -> 其他
- severity: SeverityLevel.MEDIUM -> SeverityLevel.UNKNOWN
- cvss_score: 未提取 -> 0.0
- cnnvd_id: 未提取 -> CNNVD-202510-2615
- data_sources: ['cve', 'nvd'] -> ['cnnvd', 'cve', 'nvd']
查看详细变更
- data_sources: ['cve'] -> ['cve', 'nvd']