CVE-2025-40007: Linux kernel · netfs: fix reference leak

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.

• ubuntu.com/security/CVE-2025-40007 (opens in a new tab)
• cve.org/CVERecord?id=CVE-2025-40007 (opens in a new tab)
• git.kernel.org/linus/4d428dca252c858bfac691c31fa95d26cd008706 (opens in a new tab)
• git.kernel.org/stable/c/4d428dca252c858bfac691c31fa95d26cd008706 (opens in a new tab)
• git.kernel.org/stable/c/8df142e93098b4531fadb5dfcf93087649f570b3 (opens in a new tab)

• CVE-2026-98373: Linux kernel · mm/hugetlb: preserve mremap address delta when skipping page tablesMediumVulnerability2026-10-07
• CVE-2026-98374: Linux kernel · tcp: fix use-after-free of retransmit_skb_hint in tcp_send_synack()MediumVulnerability2026-10-07
• CVE-2026-98376: Linux kernel · bpf: Use array_map_meta_equal for percpu array inner map replacementMediumVulnerability2026-10-09
• CVE-2026-98378: Linux kernel · bpf: Skip unsettled links in link iteratorMediumVulnerability2026-10-09
• CVE-2026-98380: Linux kernel · net/sched: reject IDR error pointers when deleting actionsMediumVulnerability2026-10-09