CVE-2026-53320

What it actually does

This is an improper input validation flaw in the Linux kernel NILFS2 filesystem garbage-collection ioctl handling. A malformed NILFS2 mark-blocks-dirty ioctl request can set bd_oblocknr to 0, a value that should never be accepted as a valid garbage-collection target because block 0 is reserved for the primary superblock. Under the vulnerable logic, a failed block lookup can return -ENOENT and leave the current block number as 0, causing the dead-block check to be bypassed and nilfs_bmap_mark() to be called on a non-existent block. The result is a kernel WARN_ON condition in NILFS2 btree lookup handling. The most likely technical impact is local denial of service or system instability through kernel warning/panic behavior, depending on kernel panic-on-warn configuration and system hardening settings.

Why it matters to the business

Systems that allow local users or workloads to mount or interact with NILFS2 filesystems may be exposed to kernel instability or denial of service. In environments where kernel warnings are configured to trigger a panic, exploitation could crash the host and interrupt workloads. The CVE is not currently listed in CISA KEV, is not known to be used in ransomware campaigns, has no reported exploit maturity, and has a very low EPSS score, so broad active exploitation is unlikely at this time; however, the operational risk is higher for multi-user Linux systems, container hosts with broad device/filesystem access, and systems using NILFS2.

How an attack unfolds

An attacker needs local ability to issue NILFS2 filesystem ioctl operations against a NILFS2 mount or device. They craft a malformed request to nilfs_ioctl_mark_blocks_dirty() where bd_oblocknr is set to 0. Because vulnerable kernels do not reject that invalid value early, the NILFS2 garbage-collection block handling can misclassify the missing block state when lookup returns -ENOENT and bd_blocknr is 0. The code then attempts to mark a non-existent block through NILFS2 bmap logic, triggering a WARN_ON in nilfs_btree_do_lookup(). If the system treats kernel warnings as fatal, this can crash the kernel; otherwise, it may still generate kernel warnings and indicate filesystem subsystem instability.

How to fix it

Apply a Linux kernel version or vendor kernel update that includes the NILFS2 fix rejecting bd_oblocknr == 0 in nilfs_ioctl_mark_blocks_dirty(). If exact fixed package versions are not available from the advisory data, use the applicable distribution kernel security errata and confirm the NILFS2 patch is included. As mitigations until patching is complete, restrict untrusted local users from mounting filesystems or accessing block devices, avoid enabling NILFS2 on systems that do not require it, remove or blacklist the nilfs2 kernel module where operationally safe, and ensure containers do not receive unnecessary privileged mode, host device access, CAP_SYS_ADMIN, or filesystem mount permissions. Consider disabling panic-on-warn if availability is more important than fail-stop behavior, but treat that only as an operational mitigation, not a vulnerability fix.

How to confirm the fix worked

Confirm the running kernel has been updated to a vendor build containing the NILFS2 validation fix, then reboot into the patched kernel and verify with uname/package-manager output that the active kernel matches the fixed package. Review vendor changelogs or kernel commit references for the NILFS2 change that rejects zero bd_oblocknr in nilfs_ioctl_mark_blocks_dirty(). Check whether NILFS2 is loaded or in use with lsmod, modinfo, /proc/filesystems, findmnt, and mount output. If NILFS2 is not required, validate that the nilfs2 module is not loaded and cannot be loaded by untrusted users. For exposure validation, confirm untrusted users and containers cannot mount NILFS2 filesystems or access relevant block devices. For functional validation in a controlled test environment only, malformed NILFS2 ioctl requests should be rejected without kernel WARN_ON output.

Typical attack path

1. Gain local code execution or shell access on a Linux system where NILFS2 support is present.
2. Identify or create access to a NILFS2 filesystem, mount, or block device exposed to the attacker.
3. Open the relevant NILFS2 filesystem interface and prepare a mark-blocks-dirty ioctl request.
4. Set the request's bd_oblocknr field to 0 while otherwise shaping the request to reach nilfs_ioctl_mark_blocks_dirty().
5. Submit the malformed ioctl to the vulnerable kernel.
6. Trigger NILFS2 btree lookup behavior that returns -ENOENT and reaches the WARN_ON condition.
7. Cause kernel warning output and, on systems configured to panic on warnings, crash or reboot the host.

How to detect it

Look for signs of prior exploitation or testing in kernel logs and host telemetry. Primary sources are dmesg, journald kernel logs, /var/log/kern.log, /var/log/messages, /var/log/syslog, crash dumps, kdump/vmcore records, and EDR telemetry for local processes interacting with NILFS2 mounts or block devices. Search for kernel warning stack traces that include NILFS2 functions such as nilfs_ioctl_mark_blocks_dirty(), nilfs_bmap_mark(), nilfs_btree_do_lookup(), or WARN_ON conditions returning -ENOENT. Correlate these events with local user sessions, container activity, recent mounting of NILFS2 filesystems, access to /dev block devices, and abnormal host reboot or panic events. Because no public exploit indicators or actor-specific artifacts are known from the supplied data, detection should focus on behavioral evidence of NILFS2 ioctl abuse and kernel WARN/panic artifacts rather than network indicators.

• nilfs_ioctl_mark_blocks_dirty
• nilfs_bmap_mark
• nilfs_btree_do_lookup
• WARN_ON(ret == -ENOENT)
• NILFS2
• nilfs2
• panic_on_warn
• kernel: WARNING:
• kernel: RIP:
• /var/log/kern.log
• /var/log/messages
• /var/log/syslog
• /proc/sys/kernel/panic_on_warn
• /proc/filesystems
• /sys/module/nilfs2

What your security team should do

• Prioritize patching Linux systems that use NILFS2, allow local shell access by multiple users, run untrusted workloads, or expose block devices/filesystem mounting capabilities to containers or tenants.
• Inventory NILFS2 usage across Linux fleets using kernel module, filesystem, mount, and package telemetry.
• Restrict CAP_SYS_ADMIN, privileged containers, hostPath/device passthrough, and untrusted filesystem mounting paths that could allow local ioctl abuse.
• Review kernel panic-on-warn settings on availability-critical systems because this flaw may become a crash if warnings are configured as fatal.
• Add detections for NILFS2 kernel WARN traces involving nilfs_ioctl_mark_blocks_dirty, nilfs_bmap_mark, or nilfs_btree_do_lookup.
• Monitor vendor kernel advisories and deploy the first fixed kernel available for each distribution, even though EPSS is currently low and the CVE is not in KEV.
• If NILFS2 is not used, disable or blacklist the nilfs2 kernel module as a defense-in-depth measure.