CVE-2025-40007
Unknown Unknown - Not Provided
BaseFortify

Publication date: 2025-10-20

Last updated on: 2025-10-21

Assigner: kernel.org

Description
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.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2025-10-20
Last Modified
2025-10-21
Generated
2026-05-07
AI Q&A
2025-10-20
EPSS Evaluated
2026-05-05
NVD
CVE-2025-40007
EUVD
EUVD-2025-35073
Affected Vendors & Products
Showing 1 associated CPE
Vendor Product Version / Range
linux kernel *
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 is a reference leak in the Linux kernel's netfs subsystem. Specifically, the reference counter for netfs I/O requests was initialized incorrectly, causing some requests to never be fully released if they failed early before submitting I/O. This leads to leaked references that block tasks waiting for I/O completion, causing deadlocks and outages in systems using netfs, such as Ceph clusters.


How can this vulnerability impact me? :

The vulnerability can cause server outages and deadlocks by blocking tasks indefinitely in netfs_wait_for_outstanding_io(). This happens because leaked netfs I/O requests keep internal counters positive forever, preventing proper resource cleanup and stalling operations that depend on netfs I/O completion.


What immediate steps should I take to mitigate this vulnerability?

Apply the patch that fixes the reference leak in the netfs subsystem of the Linux kernel, specifically the commit that modifies netfs_alloc_request() to initialize the reference counter to 2 and adds netfs_put_failed_request() to properly free failed requests. This patch addresses the issue of leaked references causing deadlocks. Until patched, monitor for tasks blocked in netfs_wait_for_outstanding_io() and consider kernel updates or workarounds that prevent early release of netfs_io_request objects before I/O submission.


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