https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Sat, 03 Oct 2026 09:12:57 +0000 https://cve.radiocsirt.org/vuln/bdu:2026-02702 bdu:2026-02702 https://cve.radiocsirt.org/vuln/bdu:2026-02702 https://cve.radiocsirt.org/vuln/bell-cve-2025-40105 <p><strong>Affected:</strong> Alpaquita:23: linux-lts, Alpaquita:25: linux-lts, Alpaquita:stream: linux-lts</p> <p><strong>Affected:</strong> Alpaquita:23: linux-lts, Alpaquita:25: linux-lts, Alpaquita:stream: linux-lts</p> https://cve.radiocsirt.org/vuln/bell-cve-2025-40105 https://cve.radiocsirt.org/vuln/certfr-2025-avi-0966 certfr-2025-avi-0966 https://cve.radiocsirt.org/vuln/certfr-2025-avi-0966 https://cve.radiocsirt.org/vuln/euvd-2026-364575 EUVD-2026-364575 https://cve.radiocsirt.org/vuln/euvd-2026-364575 https://cve.radiocsirt.org/vuln/fkie_cve-2025-40105 <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>vfs: Don&#39;t leak disconnected dentries on umount</p> <p>When user calls open_by_handle_at() on some inode that is not cached, we will create disconnected dentry for it. If such dentry is a directory, exportfs_decode_fh_raw() will then try to connect this dentry to the dentry tree through reconnect_path(). It may happen for various reasons (such as corrupted fs or race with rename) that the call to lookup_one_unlocked() in reconnect_one() will fail to find the dentry we are trying to reconnect and instead create a new dentry under the parent. Now this dentry will not be marked as disconnected although the parent still may well be disconnected (at least in case this inconsistency happened because the fs is corrupted and .. doesn&#39;t point to the real parent directory). This creates inconsistency in disconnected flags but AFAICS it was mostly harmless. At least until commit f1ee616214cb (&#34;VFS: don&#39;t keep disconnected dentries on d_anon&#34;) which removed adding of most disconnected dentries to sb-&gt;s_anon list. Thus after this commit cleanup of disconnected dentries implicitely relies on the fact that dput() will immediately reclaim such dentries. However when some leaf dentry isn&#39;t marked as disconnected, as in the scenario described above, the reclaim doesn&#39;t happen and the dentries are &#34;leaked&#34;. Memory reclaim can eventually reclaim them but otherwise they stay in memory and if umount comes first, we hit infamous &#34;Busy…</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>vfs: Don&#39;t leak disconnected dentries on umount</p> <p>When user calls open_by_handle_at() on some inode that is not cached, we will create disconnected dentry for it. If such dentry is a directory, exportfs_decode_fh_raw() will then try to connect this dentry to the dentry tree through reconnect_path(). It may happen for various reasons (such as corrupted fs or race with rename) that the call to lookup_one_unlocked() in reconnect_one() will fail to find the dentry we are trying to reconnect and instead create a new dentry under the parent. Now this dentry will not be marked as disconnected although the parent still may well be disconnected (at least in case this inconsistency happened because the fs is corrupted and .. doesn&#39;t point to the real parent directory). This creates inconsistency in disconnected flags but AFAICS it was mostly harmless. At least until commit f1ee616214cb (&#34;VFS: don&#39;t keep disconnected dentries on d_anon&#34;) which removed adding of most disconnected dentries to sb-&gt;s_anon list. Thus after this commit cleanup of disconnected dentries implicitely relies on the fact that dput() will immediately reclaim such dentries. However when some leaf dentry isn&#39;t marked as disconnected, as in the scenario described above, the reclaim doesn&#39;t happen and the dentries are &#34;leaked&#34;. Memory reclaim can eventually reclaim them but otherwise they stay in memory and if umount comes first, we hit infamous &#34;Busy…</p> https://cve.radiocsirt.org/vuln/fkie_cve-2025-40105 https://cve.radiocsirt.org/vuln/ghsa-9wgm-cmcc-8467 <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>vfs: Don&#39;t leak disconnected dentries on umount</p> <p>When user calls open_by_handle_at() on some inode that is not cached, we will create disconnected dentry for it. If such dentry is a directory, exportfs_decode_fh_raw() will then try to connect this dentry to the dentry tree through reconnect_path(). It may happen for various reasons (such as corrupted fs or race with rename) that the call to lookup_one_unlocked() in reconnect_one() will fail to find the dentry we are trying to reconnect and instead create a new dentry under the parent. Now this dentry will not be marked as disconnected although the parent still may well be disconnected (at least in case this inconsistency happened because the fs is corrupted and .. doesn&#39;t point to the real parent directory). This creates inconsistency in disconnected flags but AFAICS it was mostly harmless. At least until commit f1ee616214cb (&#34;VFS: don&#39;t keep disconnected dentries on d_anon&#34;) which removed adding of most disconnected dentries to sb-&gt;s_anon list. Thus after this commit cleanup of disconnected dentries implicitely relies on the fact that dput() will immediately reclaim such dentries. However when some leaf dentry isn&#39;t marked as disconnected, as in the scenario described above, the reclaim doesn&#39;t happen and the dentries are &#34;leaked&#34;. Memory reclaim can eventually reclaim them but otherwise they stay in memory and if umount comes first, we hit infamous &#34;Busy…</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>vfs: Don&#39;t leak disconnected dentries on umount</p> <p>When user calls open_by_handle_at() on some inode that is not cached, we will create disconnected dentry for it. If such dentry is a directory, exportfs_decode_fh_raw() will then try to connect this dentry to the dentry tree through reconnect_path(). It may happen for various reasons (such as corrupted fs or race with rename) that the call to lookup_one_unlocked() in reconnect_one() will fail to find the dentry we are trying to reconnect and instead create a new dentry under the parent. Now this dentry will not be marked as disconnected although the parent still may well be disconnected (at least in case this inconsistency happened because the fs is corrupted and .. doesn&#39;t point to the real parent directory). This creates inconsistency in disconnected flags but AFAICS it was mostly harmless. At least until commit f1ee616214cb (&#34;VFS: don&#39;t keep disconnected dentries on d_anon&#34;) which removed adding of most disconnected dentries to sb-&gt;s_anon list. Thus after this commit cleanup of disconnected dentries implicitely relies on the fact that dput() will immediately reclaim such dentries. However when some leaf dentry isn&#39;t marked as disconnected, as in the scenario described above, the reclaim doesn&#39;t happen and the dentries are &#34;leaked&#34;. Memory reclaim can eventually reclaim them but otherwise they stay in memory and if umount comes first, we hit infamous &#34;Busy…</p> https://cve.radiocsirt.org/vuln/ghsa-9wgm-cmcc-8467 https://cve.radiocsirt.org/vuln/icsa-26-209-04 <p>Multiple vulnerabilities have been identified in the additional GNU/Linux subsystem of the firmware version V3.1.6 for the SIMATIC S7-1500 CPU 1518(F)-4 PN/DP MFP (incl. SIPLUS variant).</p> <p>Siemens is preparing fix versions and recommends specific countermeasures for products where fixes are not, or not yet available.</p> <p>Multiple vulnerabilities have been identified in the additional GNU/Linux subsystem of the firmware version V3.1.6 for the SIMATIC S7-1500 CPU 1518(F)-4 PN/DP MFP (incl. SIPLUS variant).</p> <p>Siemens is preparing fix versions and recommends specific countermeasures for products where fixes are not, or not yet available.</p> https://cve.radiocsirt.org/vuln/icsa-26-209-04 https://cve.radiocsirt.org/vuln/msrc_cve-2025-40105 msrc_CVE-2025-40105 https://cve.radiocsirt.org/vuln/msrc_cve-2025-40105 https://cve.radiocsirt.org/vuln/oesa-2026-1303 <p><strong>Affected:</strong> openEuler:24.03-LTS: kernel</p> <p>The Linux Kernel, the operating system core itself. Security Fix(es):</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>ptr_ring: do not block hard interrupts in ptr_ring_resize_multiple()</p> <p>Jakub added a lockdep_assert_no_hardirq() check in __page_pool_put_page() to increase test coverage.</p> <p>syzbot found a splat caused by hard irq blocking in ptr_ring_resize_multiple() [1]</p> <p>As current users of ptr_ring_resize_multiple() do not require hard irqs being masked, replace it to only block BH.</p> <p>Rename helpers to better reflect they are safe against BH only.</p> <p>- ptr_ring_resize_multiple() to ptr_ring_resize_multiple_bh() - skb_array_resize_multiple() to skb_array_resize_multiple_bh()</p> <p>[1]</p> <p>WARNING: CPU: 1 PID: 9150 at net/core/page_pool.c:709 __page_pool_put_page net/core/page_pool.c:709 [inline] WARNING: CPU: 1 PID: 9150 at net/core/page_pool.c:709 page_pool_put_unrefed_netmem+0x157/0xa40 net/core/page_pool.c:780 Modules linked in: CPU: 1 UID: 0 PID: 9150 Comm: syz.1.1052 Not tainted 6.11.0-rc3-syzkaller-00202-gf8669d7b5f5d #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 RIP: 0010:__page_pool_put_page net/core/page_pool.c:709 [inline] RIP: 0010:page_pool_put_unrefed_netmem+0x157/0xa40 net/core/page_pool.c:780 Code: 74 0e e8 7c aa fb f7 eb 43 e8 75 aa fb f7 eb 3c 65 8b 1d 38 a8 6a 76 31 ff 89 de e8 a3 ae fb f7 85 db 74 0b e8 5a aa fb f7 90 &amp;lt;0f&amp;gt; 0b 90 eb 1d 65 8b 1d 15 a8 6a 76 31 ff 89 de e8 84 ae fb f7 85 RSP:…</p> <p><strong>Affected:</strong> openEuler:24.03-LTS: kernel</p> <p>The Linux Kernel, the operating system core itself. Security Fix(es):</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>ptr_ring: do not block hard interrupts in ptr_ring_resize_multiple()</p> <p>Jakub added a lockdep_assert_no_hardirq() check in __page_pool_put_page() to increase test coverage.</p> <p>syzbot found a splat caused by hard irq blocking in ptr_ring_resize_multiple() [1]</p> <p>As current users of ptr_ring_resize_multiple() do not require hard irqs being masked, replace it to only block BH.</p> <p>Rename helpers to better reflect they are safe against BH only.</p> <p>- ptr_ring_resize_multiple() to ptr_ring_resize_multiple_bh() - skb_array_resize_multiple() to skb_array_resize_multiple_bh()</p> <p>[1]</p> <p>WARNING: CPU: 1 PID: 9150 at net/core/page_pool.c:709 __page_pool_put_page net/core/page_pool.c:709 [inline] WARNING: CPU: 1 PID: 9150 at net/core/page_pool.c:709 page_pool_put_unrefed_netmem+0x157/0xa40 net/core/page_pool.c:780 Modules linked in: CPU: 1 UID: 0 PID: 9150 Comm: syz.1.1052 Not tainted 6.11.0-rc3-syzkaller-00202-gf8669d7b5f5d #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 RIP: 0010:__page_pool_put_page net/core/page_pool.c:709 [inline] RIP: 0010:page_pool_put_unrefed_netmem+0x157/0xa40 net/core/page_pool.c:780 Code: 74 0e e8 7c aa fb f7 eb 43 e8 75 aa fb f7 eb 3c 65 8b 1d 38 a8 6a 76 31 ff 89 de e8 a3 ae fb f7 85 db 74 0b e8 5a aa fb f7 90 &amp;lt;0f&amp;gt; 0b 90 eb 1d 65 8b 1d 15 a8 6a 76 31 ff 89 de e8 84 ae fb f7 85 RSP:…</p> https://cve.radiocsirt.org/vuln/oesa-2026-1303 https://cve.radiocsirt.org/vuln/opensuse-su-2025:15702-1 <p>kernel-devel-6.17.7-1.1 on GA media</p> <p>kernel-devel-6.17.7-1.1 on GA media</p> https://cve.radiocsirt.org/vuln/opensuse-su-2025:15702-1 https://cve.radiocsirt.org/vuln/ssa-019113 <p>Multiple vulnerabilities have been identified in the additional GNU/Linux subsystem of the firmware version V3.1.6 for the SIMATIC S7-1500 CPU 1518(F)-4 PN/DP MFP (incl. SIPLUS variant).</p> <p>Siemens has released new versions for several affected products and recommends to update to the latest versions. Siemens is preparing further fix versions and recommends specific countermeasures for products where fixes are not, or not yet available.</p> <p>Multiple vulnerabilities have been identified in the additional GNU/Linux subsystem of the firmware version V3.1.6 for the SIMATIC S7-1500 CPU 1518(F)-4 PN/DP MFP (incl. SIPLUS variant).</p> <p>Siemens has released new versions for several affected products and recommends to update to the latest versions. Siemens is preparing further fix versions and recommends specific countermeasures for products where fixes are not, or not yet available.</p> https://cve.radiocsirt.org/vuln/ssa-019113 https://cve.radiocsirt.org/vuln/suse-su-2025:4422-1 <p>Security update for the Linux Kernel</p> <p>Security update for the Linux Kernel</p> https://cve.radiocsirt.org/vuln/suse-su-2025:4422-1 https://cve.radiocsirt.org/vuln/ubuntu-cve-2025-40105 <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:Pro:18.04:LTS: linux-aws-5.4, Ubuntu:18.04:LTS: linux-azure, Ubuntu:18.04:LTS: linux-azure-5.3, Ubuntu:Pro:18.04:LTS: linux-azure-5.4, Ubuntu:18.04:LTS: linux-azure-edge, Ubuntu:18.04:LTS: linux-gcp, Ubuntu:18.04:LTS: linux-gcp-5.3 and 201 more</p> <p>In the Linux kernel, the following vulnerability has been resolved: vfs: Don&#39;t leak disconnected dentries on umount When user calls open_by_handle_at() on some inode that is not cached, we will create disconnected dentry for it. If such dentry is a directory, exportfs_decode_fh_raw() will then try to connect this dentry to the dentry tree through reconnect_path(). It may happen for various reasons (such as corrupted fs or race with rename) that the call to lookup_one_unlocked() in reconnect_one() will fail to find the dentry we are trying to reconnect and instead create a new dentry under the parent. Now this dentry will not be marked as disconnected although the parent still may well be disconnected (at least in case this inconsistency happened because the fs is corrupted and .. doesn&#39;t point to the real parent directory). This creates inconsistency in disconnected flags but AFAICS it was mostly harmless. At least until commit f1ee616214cb (&#34;VFS: don&#39;t keep disconnected dentries on d_anon&#34;) which removed adding of most disconnected dentries to sb-&gt;s_anon list. Thus after this commit cleanup of disconnected dentries implicitely relies on the fact that dput() will immediately reclaim such dentries. However when some leaf dentry isn&#39;t marked as disconnected, as in the scenario described above, the reclaim doesn&#39;t happen and the dentries are &#34;leaked&#34;. Memory reclaim can eventually reclaim them but otherwise they stay in memory and if umount comes first, we hit infamous &#34;Busy in…</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:Pro:18.04:LTS: linux-aws-5.4, Ubuntu:18.04:LTS: linux-azure, Ubuntu:18.04:LTS: linux-azure-5.3, Ubuntu:Pro:18.04:LTS: linux-azure-5.4, Ubuntu:18.04:LTS: linux-azure-edge, Ubuntu:18.04:LTS: linux-gcp, Ubuntu:18.04:LTS: linux-gcp-5.3 and 201 more</p> <p>In the Linux kernel, the following vulnerability has been resolved: vfs: Don&#39;t leak disconnected dentries on umount When user calls open_by_handle_at() on some inode that is not cached, we will create disconnected dentry for it. If such dentry is a directory, exportfs_decode_fh_raw() will then try to connect this dentry to the dentry tree through reconnect_path(). It may happen for various reasons (such as corrupted fs or race with rename) that the call to lookup_one_unlocked() in reconnect_one() will fail to find the dentry we are trying to reconnect and instead create a new dentry under the parent. Now this dentry will not be marked as disconnected although the parent still may well be disconnected (at least in case this inconsistency happened because the fs is corrupted and .. doesn&#39;t point to the real parent directory). This creates inconsistency in disconnected flags but AFAICS it was mostly harmless. At least until commit f1ee616214cb (&#34;VFS: don&#39;t keep disconnected dentries on d_anon&#34;) which removed adding of most disconnected dentries to sb-&gt;s_anon list. Thus after this commit cleanup of disconnected dentries implicitely relies on the fact that dput() will immediately reclaim such dentries. However when some leaf dentry isn&#39;t marked as disconnected, as in the scenario described above, the reclaim doesn&#39;t happen and the dentries are &#34;leaked&#34;. Memory reclaim can eventually reclaim them but otherwise they stay in memory and if umount comes first, we hit infamous &#34;Busy in…</p> https://cve.radiocsirt.org/vuln/ubuntu-cve-2025-40105 https://cve.radiocsirt.org/vuln/wid-sec-w-2025-2450 <p>Ein Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um nicht näher spezifizierte Angriffe durchzuführen, die möglicherweise zu einer Denial-of-Service-Situation führen oder eine Speicherbeschädigung verursachen können.</p> <p>Ein Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um nicht näher spezifizierte Angriffe durchzuführen, die möglicherweise zu einer Denial-of-Service-Situation führen oder eine Speicherbeschädigung verursachen können.</p> https://cve.radiocsirt.org/vuln/wid-sec-w-2025-2450