# CVE-2025-40007: linux: In the Linux kernel, the following vulnerability has been resolved:  netfs: fix reference leak  Commit 20d72b00ca81 (...

CVE-2025-40007 is fixed in linux on 1 platform by DEBIAN-CVE-2025-40007 (version 6.16.10-1), released October 20, 2025. It is not reported as exploited. Patch Radar priority: Routine.

- Web page: https://patchblox.com/security/cve/CVE-2025-40007
- Priority: Routine
- CVSS: n/a
- EPSS: 0.0023
- CISA KEV: not listed
- Exploited (vendor report): no
- Publicly disclosed: no
- Published: Oct 20, 2025

## 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.

## Where it's fixed

| Platform | Product | Fixed in | Fix | Released |
|---|---|---|---|---|
| Linux | linux Debian 14 | 6.16.10-1 | [DEBIAN-CVE-2025-40007](https://patchblox.com/security/data/fix/linux/debian-cve-2025-40007.md) | Oct 20, 2025 |

---

Data as of 2026-11-09T07:25:28Z UTC. Source: Patchblox Patch Radar (https://patchblox.com/security/patch-radar). Patchblox finds out-of-date software on Windows, macOS and Linux and updates it through release rings: https://patchblox.com/demo

Free to use with attribution: show "Data: Patchblox Patch Radar" with a link to https://patchblox.com/security/patch-radar. Terms, including what needs a written agreement: https://patchblox.com/security/patch-radar/use-the-data

Product names, logos and trademarks shown on Patch Radar belong to their respective owners. They are used only to identify the software each security fix applies to and to help readers find their platform. Their use does not imply any affiliation with, or endorsement by, those owners, and Patchblox is not affiliated with any of them.