CVE-2024-42105

What it actually does

The flaw permits a corrupted nilfs2 superblock to supply an ns_first_ino value that overlaps reserved inode numbers or exceeds safe bit-shift limits, disabling NILFS_MDT_INODE and NILFS_VALID_INODE macros and enabling use-after-free of internal inodes.

Why it matters to the business

Organizations running Linux systems that use the nilfs2 filesystem face elevated risk of kernel crashes, data corruption, or local privilege escalation when mounting attacker-supplied or corrupted volumes; the low EPSS and absence from KEV indicate limited in-the-wild exploitation but still require prompt patching of production kernels.

How an attack unfolds

An attacker prepares a malicious nilfs2 filesystem image whose superblock contains an ns_first_ino value that collides with reserved inode ranges, then causes a victim system to mount the image; subsequent inode allocation or lookup operations invoke the broken validation macros, resulting in use-after-free of kernel objects that can be leveraged for code execution.

How to fix it

Upgrade the Linux kernel to a version containing commit 57235c3c88bb430043728d0d02f44a4efe386476 or later; rebuild and reboot all affected systems; for environments that cannot immediately patch, restrict mounting of nilfs2 volumes from untrusted sources.

How to confirm the fix worked

Confirm the running kernel source contains the lower-bound check on ns_first_ino and the unsigned type change; attempt to mount a test image with ns_first_ino set below NILFS_USER_INO and verify the mount is rejected or handled safely; inspect /proc/fs/nilfs2 or kernel logs for absence of the prior macro misbehavior.

Typical attack path

1. Craft or obtain a nilfs2 filesystem image with manipulated ns_first_ino in the superblock
2. Induce the target to mount the image (via USB, network share, or container)
3. Trigger inode creation or metadata operations that exercise the faulty validation macros
4. Exploit resulting use-after-free to corrupt kernel memory or escalate privileges

How to detect it

Search kernel logs and audit trails for nilfs2 mount attempts from external media; monitor for oops or use-after-free reports referencing nilfs2 inode macros; examine any captured malicious filesystem images for superblock fields with ns_first_ino values outside the expected range.

• ns_first_ino
• NILFS_MDT_INODE
• NILFS_VALID_INODE
• nilfs2: bad inode number

What your security team should do

• Prioritize kernel updates containing commit 57235c3c88bb430043728d0d02f44a4efe386476 across all fleets within the next maintenance window
• Add nilfs2 to the list of filesystems disallowed for untrusted media via mount options or AppArmor/SELinux policies
• Include nilfs2 superblock parsing paths in future kernel fuzzing and static-analysis runs
• Review backup and recovery procedures for nilfs2 volumes in case corruption is discovered post-patch