CVE-2025-40007

published 2025-10-20

CVE-2025-40007: 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…

Priority P4 24 medium 5.5

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 approa

Affected

8 ranges

Vendor	Product	Version range	Fixed in
debian	linux	< linux 6.16.10-1 (forky)	linux 6.16.10-1 (forky)
linux	linux	—	—
linux	linux	—	—
linux	linux	>= 20d72b00ca814d748f5663484e5c53bb2bf37a3a < 8df142e93098b4531fadb5dfcf93087649f570b3	8df142e93098b4531fadb5dfcf93087649f570b3
linux	linux	>= 20d72b00ca814d748f5663484e5c53bb2bf37a3a < 4d428dca252c858bfac691c31fa95d26cd008706	4d428dca252c858bfac691c31fa95d26cd008706
linux	linux	>= 6.15.3 < 6.16	6.16
linux	linux_kernel	>= 0 < 6.16.10-1	6.16.10-1
linux	linux_kernel	>= 6.16.0 < 6.16.10	6.16.10

Stop checking back — get the weekly exploitation signal.

Every Monday: what got weaponized or added to CISA KEV in the last seven days — each CVE cross-linked to its PoC, Nuclei template, and detection rule. Free, one email a week, unsubscribe in one click.

CWE-911