CVE-2026-53320
MediumCVSS 5.5Exploitation Probability (EPSS)
Low risk7th percentile — higher than 7% of all known CVEs
Summary
In the Linux kernel, a vulnerability was found in the nilfs2 filesystem where the nilfs_ioctl_mark_blocks_dirty() function fails to reject a zero bd_oblocknr value. An attacker can send a crafted ioctl request with bd_oblocknr set to 0, bypassing the dead block check and calling nilfs_bmap_mark() on a non-existent block, triggering a WARN_ON and potentially causing system disruption.
Risk Assessment
The risk involves potential system crash (kernel panic) or unexpected behavior by sending a specially crafted ioctl request to the nilfs2 filesystem, which could be exploited for a DoS attack.
Recommendation
Immediately update the Linux kernel to a version containing the fix that rejects ioctl requests with bd_oblocknr set to 0 in nilfs_ioctl_mark_blocks_dirty().
Original NVD description (English source)
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]