https://vulnerability.circl.lu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Tue, 29 Sep 2026 05:19:02 +0000 https://vulnerability.circl.lu/vuln/cve-2025-40007 <p><strong>Affected:</strong> Linux</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>netfs: fix reference leak</p> <p>Commit 20d72b00ca81 (&#34;netfs: Fix the request&#39;s work item to not require a ref&#34;) modified netfs_alloc_request() to initialize the reference counter to 2 instead of 1. The rationale was that the requet&#39;s &#34;work&#34; would release the second reference after completion (via netfs_{read,write}_collection_worker()). That works most of the time if all goes well.</p> <p>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.</p> <p>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.</p> <p>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:</p> <p>- Some functions like netfs_create_write_req() allocate a request, but will never submit any I/O.</p> <p>- netfs_unbuffered_read_iter_locked() calls netfs_unbuffered_read() and then netfs_put_request(); however, netfs_unb…</p> <p><strong>Affected:</strong> Linux</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>netfs: fix reference leak</p> <p>Commit 20d72b00ca81 (&#34;netfs: Fix the request&#39;s work item to not require a ref&#34;) modified netfs_alloc_request() to initialize the reference counter to 2 instead of 1. The rationale was that the requet&#39;s &#34;work&#34; would release the second reference after completion (via netfs_{read,write}_collection_worker()). That works most of the time if all goes well.</p> <p>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.</p> <p>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.</p> <p>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:</p> <p>- Some functions like netfs_create_write_req() allocate a request, but will never submit any I/O.</p> <p>- netfs_unbuffered_read_iter_locked() calls netfs_unbuffered_read() and then netfs_put_request(); however, netfs_unb…</p> https://vulnerability.circl.lu/vuln/cve-2025-40007