https://vulnerability.circl.lu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Tue, 29 Sep 2026 03:54:58 +0000 https://vulnerability.circl.lu/vuln/cve-2026-53320 <p><strong>Affected:</strong> Linux</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> <p><strong>Affected:</strong> Linux</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://vulnerability.circl.lu/vuln/cve-2026-53320