CVE-2023-53845

What it actually does

nilfs2 metadata block lookup in the Linux kernel enters an infinite loop on invalid virtual block addresses from a corrupted filesystem image, repeatedly calling read/create paths and potentially leaving i_rwsem held on the inode metadata file.

Why it matters to the business

Mounting a corrupted nilfs2 filesystem can cause kernel tasks to hang indefinitely in lock_mount, leading to system unresponsiveness, degraded availability, and potential need for manual intervention or reboot on affected Linux systems.

How an attack unfolds

An attacker supplies or tricks a system into mounting a crafted nilfs2 disk image containing invalid virtual block addresses; the flawed lookup return code handling causes repeated block operations that hold semaphores and stall mount operations.

How to fix it

Upgrade the Linux kernel to a version containing commit cfb0bb4fbd40c1f06da7e9f88c0a2d46155b90c2 or later; for Ubuntu 20.04 LTS update libpodofo to 0.9.6+dfsg-5 or newer; rebuild and reboot with the patched kernel; avoid mounting untrusted nilfs2 images until updated.

How to confirm the fix worked

Confirm the running kernel contains the fix commit; attempt to mount a test corrupted nilfs2 image in a controlled environment and verify no infinite loop or semaphore hang occurs; check dmesg and kernel logs for corruption warnings instead of hangs.

Typical attack path

1. Prepare or obtain a nilfs2 filesystem image with invalid virtual block addresses in metadata
2. Cause the target system to mount the image (local, USB, network share, or container)
3. Trigger nilfs_bmap_lookup_at_level returning duplicated -ENOENT on ifile or other metadata
4. nilfs_mdt_get_block loops indefinitely creating/reading blocks while holding i_rwsem
5. Mount-related kernel tasks hang, impacting system stability

How to detect it

Search kernel logs and dmesg for repeated nilfs_mdt_get_block or nilfs_bmap_lookup_at_level calls without corresponding block allocation success; monitor for processes stuck in D-state during mount operations on nilfs2 volumes; review audit logs for unexpected mount attempts of nilfs2 filesystems.

What your security team should do

• Prioritize kernel updates on all systems using nilfs2 filesystems within the next maintenance window
• Add nilfs2 to the list of filesystems requiring integrity verification before mounting untrusted images
• Update detection rules to alert on prolonged lock_mount or i_rwsem contention involving nilfs2
• Review backup and recovery procedures for systems that may encounter corrupted nilfs2 volumes