Bug 2493754 (CVE-2026-53320) - CVE-2026-53320 kernel: nilfs2: reject zero bd_oblocknr in nilfs_ioctl_mark_blocks_dirty()
Summary: CVE-2026-53320 kernel: nilfs2: reject zero bd_oblocknr in nilfs_ioctl_mark_bl...
Keywords:
Status: NEW
Alias: CVE-2026-53320
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: Product Security
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2026-06-26 21:05 UTC by OSIDB Bzimport
Modified: 2026-06-29 08:43 UTC (History)
2 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed:
Embargoed:


Attachments (Terms of Use)

Description OSIDB Bzimport 2026-06-26 21:05:16 UTC
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]

Comment 1 Mauro Matteo Cascella 2026-06-29 08:38:58 UTC
Upstream advisory:
https://lore.kernel.org/linux-cve-announce/2026062622-CVE-2026-53320-a56a@gregkh/T


Note You need to log in before you can comment on or make changes to this bug.