Skip to content
VulniPulse
Advisory severityUnratedRed Hat Linux

Advisory [CVE-2026-53320] reject zero bd_oblocknr in nilfs_ioctl_mark_blocks_dirty

This Red Hat Linux security advisory covers CVE-2026-53320.

Aggregated and source-linked by VulniPulse. Data sources, validation and limitations.

CVE-2026-53320 Source published Source updated

VulniPulse record published Record updated

CVE-2026-53320
Affected products & platforms
Red Hat LinuxUnclassified
Open source advisory

Summary

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] A local attacker could exploit this vulnerability by sending a specially crafted input/output control (ioctl) request to the `nilfs_ioctl_mark_blocks_dirty()` function.

By providing a zero block number, the attacker can bypass a critical dead block check, causing the system to attempt operations on a non-existent block. This ultimately leads to a system crash, resulting in a Denial of Service (DoS).

Red Hat severity: not rated.

Is CVE-2026-53320 exploited?

No exploitation is reported in the sources VulniPulse tracks: CVE-2026-53320 is not in the CISA KEV catalog (checked ) and this advisory does not report exploitation. That is not proof the vulnerability cannot be exploited.

How do I fix CVE-2026-53320?

The advisory VulniPulse tracks names no fixed release. Follow Red Hat's guidance for workarounds and updates.

Confirm against the vendor advisory before you patch.

Affected versions

No affected-version range was extracted from the source record. The vendor advisory is authoritative. Check it before change work.

Official advisory · medium-confidence parse· fetched 16 days ago·verify at source

Fixed versions

No fixed release is recorded yet. That does not prove no patch exists. Confirm against the vendor advisory.

Official advisory · medium-confidence parse· fetched 16 days ago·verify at source

Mitigation

The source record does not include mitigation steps. That does not mean no fix exists. Read the vendor advisory below for the authoritative guidance.

Official advisory · medium-confidence parse· fetched 16 days ago·verify at source

Get an email when Red Hat publishes the next one.

See Red Hat's last 90 days of advisories first. Then choose one product with live alerts free for life, or a free month of real-time alerts on everything with the severity, the fixed version and the vendor's link (card needed, then US$15/month; we email you before the first charge).

Alert me about Red Hat
All Red Hat Linux advisories

iPhone and Android apps · New on the App Store

Monitor future Red Hat Linux CVEs from your phone.

Choose a whole vendor or a precise platform, then receive matching security advisories by phone notification, email, or both. Coverage follows 34 official vendor sources and 160+ reviewed platform categories.

Discussion(0)

No comments yet. Share field notes, upgrade gotchas, or questions — verify against the vendor advisory before acting on community advice.

Sign in to join the discussion.