https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Mon, 05 Oct 2026 17:42:26 +0000 https://cve.radiocsirt.org/vuln/bdu:2025-13577 bdu:2025-13577 https://cve.radiocsirt.org/vuln/bdu:2025-13577 https://cve.radiocsirt.org/vuln/bell-cve-2025-40007 <p><strong>Affected:</strong> Alpaquita:stream: linux-lts</p> <p><strong>Affected:</strong> Alpaquita:stream: linux-lts</p> https://cve.radiocsirt.org/vuln/bell-cve-2025-40007 https://cve.radiocsirt.org/vuln/certfr-2025-avi-0969 certfr-2025-avi-0969 https://cve.radiocsirt.org/vuln/certfr-2025-avi-0969 https://cve.radiocsirt.org/vuln/euvd-2026-320880 EUVD-2026-320880 https://cve.radiocsirt.org/vuln/euvd-2026-320880 https://cve.radiocsirt.org/vuln/fkie_cve-2025-40007 <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>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://cve.radiocsirt.org/vuln/fkie_cve-2025-40007 https://cve.radiocsirt.org/vuln/ghsa-gvqp-7rxr-73ch <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>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://cve.radiocsirt.org/vuln/ghsa-gvqp-7rxr-73ch https://cve.radiocsirt.org/vuln/ubuntu-cve-2025-40007 <p><strong>Affected:</strong> Ubuntu:16.04:LTS: linux-hwe-edge, Ubuntu:18.04:LTS: linux-aws-5.0, Ubuntu:18.04:LTS: linux-aws-5.3, Ubuntu:18.04:LTS: linux-azure, Ubuntu:18.04:LTS: linux-azure-5.3, Ubuntu:18.04:LTS: linux-azure-edge, Ubuntu:18.04:LTS: linux-gcp, Ubuntu:18.04:LTS: linux-gcp-5.3, Ubuntu:18.04:LTS: linux-gke-4.15, Ubuntu:18.04:LTS: linux-gke-5.4 and 96 more</p> <p>In the Linux kernel, the following vulnerability has been resolved: netfs: fix reference leak 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. 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…</p> <p><strong>Affected:</strong> Ubuntu:16.04:LTS: linux-hwe-edge, Ubuntu:18.04:LTS: linux-aws-5.0, Ubuntu:18.04:LTS: linux-aws-5.3, Ubuntu:18.04:LTS: linux-azure, Ubuntu:18.04:LTS: linux-azure-5.3, Ubuntu:18.04:LTS: linux-azure-edge, Ubuntu:18.04:LTS: linux-gcp, Ubuntu:18.04:LTS: linux-gcp-5.3, Ubuntu:18.04:LTS: linux-gke-4.15, Ubuntu:18.04:LTS: linux-gke-5.4 and 96 more</p> <p>In the Linux kernel, the following vulnerability has been resolved: netfs: fix reference leak 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. 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…</p> https://cve.radiocsirt.org/vuln/ubuntu-cve-2025-40007 https://cve.radiocsirt.org/vuln/wid-sec-w-2025-2350 <p>Ein Angreifer kann mehrere Schwachstellen in Linux Kernel ausnutzen, um einen Denial of Service Angriff durchzuführen oder andere, nicht näher bezeichnete Angriffe durchzuführen.</p> <p>Ein Angreifer kann mehrere Schwachstellen in Linux Kernel ausnutzen, um einen Denial of Service Angriff durchzuführen oder andere, nicht näher bezeichnete Angriffe durchzuführen.</p> https://cve.radiocsirt.org/vuln/wid-sec-w-2025-2350