https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Fri, 09 Oct 2026 09:21:34 +0000 https://cve.radiocsirt.org/vuln/bell-cve-2026-53320 <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-53320 https://cve.radiocsirt.org/vuln/certfr-2026-avi-0862 certfr-2026-avi-0862 https://cve.radiocsirt.org/vuln/certfr-2026-avi-0862 https://cve.radiocsirt.org/vuln/euvd-2026-330809 EUVD-2026-330809 https://cve.radiocsirt.org/vuln/euvd-2026-330809 https://cve.radiocsirt.org/vuln/fkie_cve-2026-53320 <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>nilfs2: reject zero bd_oblocknr in nilfs_ioctl_mark_blocks_dirty()</p> <p>nilfs_ioctl_mark_blocks_dirty() uses bd_oblocknr to detect dead blocks by comparing it with the current block number bd_blocknr. If they differ, the block is considered dead and skipped.</p> <p>However, bd_oblocknr should never be 0 since block 0 typically stores the primary superblock and is never a valid GC target block. A corrupted ioctl request with bd_oblocknr set to 0 causes the comparison to incorrectly match when the lookup returns -ENOENT and sets bd_blocknr to 0, bypassing the dead block check and calling nilfs_bmap_mark() on a non-existent block. This causes nilfs_btree_do_lookup() to return -ENOENT, triggering the WARN_ON(ret == -ENOENT).</p> <p>Fix this by rejecting ioctl requests with bd_oblocknr set to 0 at the beginning of each iteration.</p> <p>[ryusuke: slightly modified the commit message and comments for accuracy]</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>nilfs2: reject zero bd_oblocknr in nilfs_ioctl_mark_blocks_dirty()</p> <p>nilfs_ioctl_mark_blocks_dirty() uses bd_oblocknr to detect dead blocks by comparing it with the current block number bd_blocknr. If they differ, the block is considered dead and skipped.</p> <p>However, bd_oblocknr should never be 0 since block 0 typically stores the primary superblock and is never a valid GC target block. A corrupted ioctl request with bd_oblocknr set to 0 causes the comparison to incorrectly match when the lookup returns -ENOENT and sets bd_blocknr to 0, bypassing the dead block check and calling nilfs_bmap_mark() on a non-existent block. This causes nilfs_btree_do_lookup() to return -ENOENT, triggering the WARN_ON(ret == -ENOENT).</p> <p>Fix this by rejecting ioctl requests with bd_oblocknr set to 0 at the beginning of each iteration.</p> <p>[ryusuke: slightly modified the commit message and comments for accuracy]</p> https://cve.radiocsirt.org/vuln/fkie_cve-2026-53320 https://cve.radiocsirt.org/vuln/ghsa-r88h-63mh-cc6h <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>nilfs2: reject zero bd_oblocknr in nilfs_ioctl_mark_blocks_dirty()</p> <p>nilfs_ioctl_mark_blocks_dirty() uses bd_oblocknr to detect dead blocks by comparing it with the current block number bd_blocknr. If they differ, the block is considered dead and skipped.</p> <p>However, bd_oblocknr should never be 0 since block 0 typically stores the primary superblock and is never a valid GC target block. A corrupted ioctl request with bd_oblocknr set to 0 causes the comparison to incorrectly match when the lookup returns -ENOENT and sets bd_blocknr to 0, bypassing the dead block check and calling nilfs_bmap_mark() on a non-existent block. This causes nilfs_btree_do_lookup() to return -ENOENT, triggering the WARN_ON(ret == -ENOENT).</p> <p>Fix this by rejecting ioctl requests with bd_oblocknr set to 0 at the beginning of each iteration.</p> <p>[ryusuke: slightly modified the commit message and comments for accuracy]</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>nilfs2: reject zero bd_oblocknr in nilfs_ioctl_mark_blocks_dirty()</p> <p>nilfs_ioctl_mark_blocks_dirty() uses bd_oblocknr to detect dead blocks by comparing it with the current block number bd_blocknr. If they differ, the block is considered dead and skipped.</p> <p>However, bd_oblocknr should never be 0 since block 0 typically stores the primary superblock and is never a valid GC target block. A corrupted ioctl request with bd_oblocknr set to 0 causes the comparison to incorrectly match when the lookup returns -ENOENT and sets bd_blocknr to 0, bypassing the dead block check and calling nilfs_bmap_mark() on a non-existent block. This causes nilfs_btree_do_lookup() to return -ENOENT, triggering the WARN_ON(ret == -ENOENT).</p> <p>Fix this by rejecting ioctl requests with bd_oblocknr set to 0 at the beginning of each iteration.</p> <p>[ryusuke: slightly modified the commit message and comments for accuracy]</p> https://cve.radiocsirt.org/vuln/ghsa-r88h-63mh-cc6h https://cve.radiocsirt.org/vuln/msrc_cve-2026-53320 msrc_CVE-2026-53320 https://cve.radiocsirt.org/vuln/msrc_cve-2026-53320 https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-53320 <p><strong>Affected:</strong> Ubuntu:Pro:14.04:LTS: linux, Ubuntu:Pro:14.04:LTS: linux-aws, Ubuntu:Pro:14.04:LTS: linux-azure, Ubuntu:Pro:14.04:LTS: linux-lts-xenial, Ubuntu:Pro:16.04:LTS: linux, Ubuntu:Pro:16.04:LTS: linux-aws, Ubuntu:Pro:16.04:LTS: linux-aws-hwe, Ubuntu:Pro:16.04:LTS: linux-azure, Ubuntu:Pro:16.04:LTS: linux-gcp, Ubuntu:Pro:16.04:LTS: linux-hwe and 254 more</p> <p>In the Linux kernel, the following vulnerability has been resolved: nilfs2: reject zero bd_oblocknr in nilfs_ioctl_mark_blocks_dirty() nilfs_ioctl_mark_blocks_dirty() uses bd_oblocknr to detect dead blocks by comparing it with the current block number bd_blocknr. If they differ, the block is considered dead and skipped. However, bd_oblocknr should never be 0 since block 0 typically stores the primary superblock and is never a valid GC target block. A corrupted ioctl request with bd_oblocknr set to 0 causes the comparison to incorrectly match when the lookup returns -ENOENT and sets bd_blocknr to 0, bypassing the dead block check and calling nilfs_bmap_mark() on a non-existent block. This causes nilfs_btree_do_lookup() to return -ENOENT, triggering the WARN_ON(ret == -ENOENT). Fix this by rejecting ioctl requests with bd_oblocknr set to 0 at the beginning of each iteration. [ryusuke: slightly modified the commit message and comments for accuracy]</p> <p><strong>Affected:</strong> Ubuntu:Pro:14.04:LTS: linux, Ubuntu:Pro:14.04:LTS: linux-aws, Ubuntu:Pro:14.04:LTS: linux-azure, Ubuntu:Pro:14.04:LTS: linux-lts-xenial, Ubuntu:Pro:16.04:LTS: linux, Ubuntu:Pro:16.04:LTS: linux-aws, Ubuntu:Pro:16.04:LTS: linux-aws-hwe, Ubuntu:Pro:16.04:LTS: linux-azure, Ubuntu:Pro:16.04:LTS: linux-gcp, Ubuntu:Pro:16.04:LTS: linux-hwe and 254 more</p> <p>In the Linux kernel, the following vulnerability has been resolved: nilfs2: reject zero bd_oblocknr in nilfs_ioctl_mark_blocks_dirty() nilfs_ioctl_mark_blocks_dirty() uses bd_oblocknr to detect dead blocks by comparing it with the current block number bd_blocknr. If they differ, the block is considered dead and skipped. However, bd_oblocknr should never be 0 since block 0 typically stores the primary superblock and is never a valid GC target block. A corrupted ioctl request with bd_oblocknr set to 0 causes the comparison to incorrectly match when the lookup returns -ENOENT and sets bd_blocknr to 0, bypassing the dead block check and calling nilfs_bmap_mark() on a non-existent block. This causes nilfs_btree_do_lookup() to return -ENOENT, triggering the WARN_ON(ret == -ENOENT). Fix this by rejecting ioctl requests with bd_oblocknr set to 0 at the beginning of each iteration. [ryusuke: slightly modified the commit message and comments for accuracy]</p> https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-53320 https://cve.radiocsirt.org/vuln/wid-sec-w-2026-2119 <p>Ein lokaler Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um Sicherheitsmaßnahmen zu umgehen, einen Denial of Service zu verursachen und potentiell Code auszuführen.</p> <p>Ein lokaler Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um Sicherheitsmaßnahmen zu umgehen, einen Denial of Service zu verursachen und potentiell Code auszuführen.</p> https://cve.radiocsirt.org/vuln/wid-sec-w-2026-2119