{"id":"DEBIAN-CVE-2025-40007","details":"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.","modified":"2026-09-01T20:05:43.318166287Z","published":"2025-10-20T16:15:37.357Z","upstream":["CVE-2025-40007"],"references":[{"type":"ADVISORY","url":"https://security-tracker.debian.org/tracker/CVE-2025-40007"}],"affected":[{"package":{"name":"linux","ecosystem":"Debian:14","purl":"pkg:deb/debian/linux?arch=source&distro=forky"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.16.10-1"}]}],"versions":["6.12.100-1","6.12.101-1","6.12.105-1","6.12.107-1","6.12.38-1","6.12.41-1","6.12.43-1","6.12.43-1~bpo12+1","6.12.48-1","6.12.57-1","6.12.57-1~bpo12+1","6.12.63-1","6.12.63-1~bpo12+1","6.12.69-1","6.12.69-1~bpo12+1","6.12.73-1","6.12.73-1~bpo12+1","6.12.74-1","6.12.74-2","6.12.74-2~bpo12+1","6.12.85-1","6.12.85-1~bpo12+1","6.12.86-1","6.12.86-1~bpo12+1","6.12.88-1","6.12.88-1~bpo12+1","6.12.90-1","6.12.90-1~bpo12+1","6.12.90-2","6.12.90-2~bpo12+1","6.12.94-1","6.12.94-1~bpo12+1","6.12.95-1","6.12.95-1~bpo12+1","6.12.96-1","6.13.10-1~exp1","6.13.11-1~exp1","6.13.2-1~exp1","6.13.3-1~exp1","6.13.4-1~exp1","6.13.5-1~exp1","6.13.6-1~exp1","6.13.7-1~exp1","6.13.8-1~exp1","6.13.9-1~exp1","6.13~rc6-1~exp1","6.13~rc7-1~exp1","6.14.3-1~exp1","6.14.5-1~exp1","6.14.6-1~exp1","6.15-1~exp1","6.15.1-1~exp1","6.15.2-1~exp1","6.15.3-1~exp1","6.15.4-1~exp1","6.15.5-1~exp1","6.15.6-1~exp1","6.15~rc7-1~exp1","6.16-1~exp1","6.16.1-1~exp1","6.16.3-1","6.16.3-1~bpo13+1","6.16.5-1","6.16.6-1","6.16.7-1","6.16.8-1","6.16.9-1","6.16~rc7-1~exp1"],"ecosystem_specific":{"urgency":"not yet assigned"},"database_specific":{"source":"https://storage.googleapis.com/debian-osv/debian-cve-osv/DEBIAN-CVE-2025-40007.json"}}],"schema_version":"1.9.0"}