https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Sat, 03 Oct 2026 14:02:13 +0000 https://cve.radiocsirt.org/vuln/bell-cve-2026-72170 <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-2026-72170 https://cve.radiocsirt.org/vuln/certfr-2026-avi-1163 certfr-2026-avi-1163 https://cve.radiocsirt.org/vuln/certfr-2026-avi-1163 https://cve.radiocsirt.org/vuln/euvd-2026-357892 EUVD-2026-357892 https://cve.radiocsirt.org/vuln/euvd-2026-357892 https://cve.radiocsirt.org/vuln/fkie_cve-2026-72170 <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>9p: skip nlink update in cacheless mode to fix WARN_ON</p> <p>v9fs_dec_count() unconditionally calls drop_nlink() on regular files, even when the inode&#39;s nlink is already zero. In cacheless mode the client refetches inode metadata from the server (the source of truth) on every operation, so by the time v9fs_remove() returns, the locally cached nlink may already reflect the post-unlink value:</p> <p>1. Client initiates unlink, server processes it and sets nlink to 0 2. Client refetches inode metadata (nlink=0) before unlink returns 3. Client&#39;s v9fs_remove() completes successfully 4. Client calls v9fs_dec_count() which calls drop_nlink() on nlink=0</p> <p>This race is easily triggered under heavy unlink workloads, such as stress-ng&#39;s unlink stressor, producing the following warning:</p> <p>WARNING: fs/inode.c:417 at drop_nlink+0x4c/0xc8 Call trace: drop_nlink+0x4c/0xc8 v9fs_remove+0x1e0/0x250 [9p] v9fs_vfs_unlink+0x20/0x38 [9p] vfs_unlink+0x13c/0x258 ...</p> <p>In cacheless mode the server is authoritative and the inode is on its way out, so locally adjusting nlink buys nothing. Skip v9fs_dec_count() entirely when neither CACHE_META nor CACHE_LOOSE is set, which both avoids the warning and removes a class of nlink races (two concurrent unlinkers observing nlink &gt; 0 and both calling drop_nlink()) that an nlink == 0 guard alone would only narrow rather than close.</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>9p: skip nlink update in cacheless mode to fix WARN_ON</p> <p>v9fs_dec_count() unconditionally calls drop_nlink() on regular files, even when the inode&#39;s nlink is already zero. In cacheless mode the client refetches inode metadata from the server (the source of truth) on every operation, so by the time v9fs_remove() returns, the locally cached nlink may already reflect the post-unlink value:</p> <p>1. Client initiates unlink, server processes it and sets nlink to 0 2. Client refetches inode metadata (nlink=0) before unlink returns 3. Client&#39;s v9fs_remove() completes successfully 4. Client calls v9fs_dec_count() which calls drop_nlink() on nlink=0</p> <p>This race is easily triggered under heavy unlink workloads, such as stress-ng&#39;s unlink stressor, producing the following warning:</p> <p>WARNING: fs/inode.c:417 at drop_nlink+0x4c/0xc8 Call trace: drop_nlink+0x4c/0xc8 v9fs_remove+0x1e0/0x250 [9p] v9fs_vfs_unlink+0x20/0x38 [9p] vfs_unlink+0x13c/0x258 ...</p> <p>In cacheless mode the server is authoritative and the inode is on its way out, so locally adjusting nlink buys nothing. Skip v9fs_dec_count() entirely when neither CACHE_META nor CACHE_LOOSE is set, which both avoids the warning and removes a class of nlink races (two concurrent unlinkers observing nlink &gt; 0 and both calling drop_nlink()) that an nlink == 0 guard alone would only narrow rather than close.</p> https://cve.radiocsirt.org/vuln/fkie_cve-2026-72170 https://cve.radiocsirt.org/vuln/ghsa-g6rc-qhh9-wvwv <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>9p: skip nlink update in cacheless mode to fix WARN_ON</p> <p>v9fs_dec_count() unconditionally calls drop_nlink() on regular files, even when the inode&#39;s nlink is already zero. In cacheless mode the client refetches inode metadata from the server (the source of truth) on every operation, so by the time v9fs_remove() returns, the locally cached nlink may already reflect the post-unlink value:</p> <p>1. Client initiates unlink, server processes it and sets nlink to 0 2. Client refetches inode metadata (nlink=0) before unlink returns 3. Client&#39;s v9fs_remove() completes successfully 4. Client calls v9fs_dec_count() which calls drop_nlink() on nlink=0</p> <p>This race is easily triggered under heavy unlink workloads, such as stress-ng&#39;s unlink stressor, producing the following warning:</p> <p>WARNING: fs/inode.c:417 at drop_nlink+0x4c/0xc8 Call trace: drop_nlink+0x4c/0xc8 v9fs_remove+0x1e0/0x250 [9p] v9fs_vfs_unlink+0x20/0x38 [9p] vfs_unlink+0x13c/0x258 ...</p> <p>In cacheless mode the server is authoritative and the inode is on its way out, so locally adjusting nlink buys nothing. Skip v9fs_dec_count() entirely when neither CACHE_META nor CACHE_LOOSE is set, which both avoids the warning and removes a class of nlink races (two concurrent unlinkers observing nlink &gt; 0 and both calling drop_nlink()) that an nlink == 0 guard alone would only narrow rather than close.</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>9p: skip nlink update in cacheless mode to fix WARN_ON</p> <p>v9fs_dec_count() unconditionally calls drop_nlink() on regular files, even when the inode&#39;s nlink is already zero. In cacheless mode the client refetches inode metadata from the server (the source of truth) on every operation, so by the time v9fs_remove() returns, the locally cached nlink may already reflect the post-unlink value:</p> <p>1. Client initiates unlink, server processes it and sets nlink to 0 2. Client refetches inode metadata (nlink=0) before unlink returns 3. Client&#39;s v9fs_remove() completes successfully 4. Client calls v9fs_dec_count() which calls drop_nlink() on nlink=0</p> <p>This race is easily triggered under heavy unlink workloads, such as stress-ng&#39;s unlink stressor, producing the following warning:</p> <p>WARNING: fs/inode.c:417 at drop_nlink+0x4c/0xc8 Call trace: drop_nlink+0x4c/0xc8 v9fs_remove+0x1e0/0x250 [9p] v9fs_vfs_unlink+0x20/0x38 [9p] vfs_unlink+0x13c/0x258 ...</p> <p>In cacheless mode the server is authoritative and the inode is on its way out, so locally adjusting nlink buys nothing. Skip v9fs_dec_count() entirely when neither CACHE_META nor CACHE_LOOSE is set, which both avoids the warning and removes a class of nlink races (two concurrent unlinkers observing nlink &gt; 0 and both calling drop_nlink()) that an nlink == 0 guard alone would only narrow rather than close.</p> https://cve.radiocsirt.org/vuln/ghsa-g6rc-qhh9-wvwv https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-72170 <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 219 more</p> <p>In the Linux kernel, the following vulnerability has been resolved: 9p: skip nlink update in cacheless mode to fix WARN_ON v9fs_dec_count() unconditionally calls drop_nlink() on regular files, even when the inode&#39;s nlink is already zero. In cacheless mode the client refetches inode metadata from the server (the source of truth) on every operation, so by the time v9fs_remove() returns, the locally cached nlink may already reflect the post-unlink value: 1. Client initiates unlink, server processes it and sets nlink to 0 2. Client refetches inode metadata (nlink=0) before unlink returns 3. Client&#39;s v9fs_remove() completes successfully 4. Client calls v9fs_dec_count() which calls drop_nlink() on nlink=0 This race is easily triggered under heavy unlink workloads, such as stress-ng&#39;s unlink stressor, producing the following warning: WARNING: fs/inode.c:417 at drop_nlink+0x4c/0xc8 Call trace: drop_nlink+0x4c/0xc8 v9fs_remove+0x1e0/0x250 [9p] v9fs_vfs_unlink+0x20/0x38 [9p] vfs_unlink+0x13c/0x258 ... In cacheless mode the server is authoritative and the inode is on its way out, so locally adjusting nlink buys nothing. Skip v9fs_dec_count() entirely when neither CACHE_META nor CACHE_LOOSE is set, which both avoids the warning and removes a class of nlink races (two concurrent unlinkers observing nlink &gt; 0 and both calling drop_nlink()) that an nlink == 0 guard alone would only narrow rather than close.</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 219 more</p> <p>In the Linux kernel, the following vulnerability has been resolved: 9p: skip nlink update in cacheless mode to fix WARN_ON v9fs_dec_count() unconditionally calls drop_nlink() on regular files, even when the inode&#39;s nlink is already zero. In cacheless mode the client refetches inode metadata from the server (the source of truth) on every operation, so by the time v9fs_remove() returns, the locally cached nlink may already reflect the post-unlink value: 1. Client initiates unlink, server processes it and sets nlink to 0 2. Client refetches inode metadata (nlink=0) before unlink returns 3. Client&#39;s v9fs_remove() completes successfully 4. Client calls v9fs_dec_count() which calls drop_nlink() on nlink=0 This race is easily triggered under heavy unlink workloads, such as stress-ng&#39;s unlink stressor, producing the following warning: WARNING: fs/inode.c:417 at drop_nlink+0x4c/0xc8 Call trace: drop_nlink+0x4c/0xc8 v9fs_remove+0x1e0/0x250 [9p] v9fs_vfs_unlink+0x20/0x38 [9p] vfs_unlink+0x13c/0x258 ... In cacheless mode the server is authoritative and the inode is on its way out, so locally adjusting nlink buys nothing. Skip v9fs_dec_count() entirely when neither CACHE_META nor CACHE_LOOSE is set, which both avoids the warning and removes a class of nlink races (two concurrent unlinkers observing nlink &gt; 0 and both calling drop_nlink()) that an nlink == 0 guard alone would only narrow rather than close.</p> https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-72170 https://cve.radiocsirt.org/vuln/wid-sec-w-2026-2852 <p>Ein Angreifer kann mehrere Schwachstellen in Linux Kernel ausnutzen, um root Rechte zu erlangen, um einen Denial of Service herbeizuführen oder einen nicht näher spezifizierten Angriff durchzuführen.</p> <p>Ein Angreifer kann mehrere Schwachstellen in Linux Kernel ausnutzen, um root Rechte zu erlangen, um einen Denial of Service herbeizuführen oder einen nicht näher spezifizierten Angriff durchzuführen.</p> https://cve.radiocsirt.org/vuln/wid-sec-w-2026-2852