CVE-2025-40007

CVE-2025-40007

published October 20, 2025

CVSS
—
EPSS
0%
Percentile
12.4
In the wild
Unconfirmed
What it is

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.

The record
Technical detail
CVSS
Not scored
CVSS v4.0
Not supplied
EPSS
0.00225 · 12.4th percentile
Published
2025-10-20T20:15Z
References (2)
EPSS history
Timeline
  • 20 OCT 15:26Z
    netfs: fix reference leak
    cvelistv5