The Linux kernel is well known for its robustness, but even the most solid systems can have small cracks. One such vulnerability was found and fixed recently in the nilfs2 filesystem. In this post, we’ll break down CVE-2024-53690, showing how a simple logic error led to use-after-delete of an inode, why it’s dangerous, and what the fix looks like — all in straightforward language.

What is nilfs2 and What Went Wrong?

nilfs2 is a log-structured file system (LFS) for Linux that aims to provide continuous snapshotting, making it valuable for systems that need high reliability. Internally, it manages “inodes,” which are data structures that describe files and directories.

In CVE-2024-53690, syzbot (an automated bug search tool) discovered the filesystem could use a deleted inode due to mishandling of its internal inode bitmap. Specifically, newly created files could reuse an inode number that should be reserved for a special directory entry, leading to inode duplication, and ultimately, logic bugs when files are removed.

Here’s what happened in more detail

1. Corrupted inode bitmap: The bitmap tracking in-use inodes was corrupted, making the kernel believe a reserved inode number was free.
2. inode reassignment: The nilfs2 code created a new directory ("file") and assigned it a reserved inode.
3. Double use: During a remove operation (rmdir), the kernel then used the same inode for two directories at once: the reserved ".nilfs" and the new "file".
4. Underflow: The inode's i_nlink field, which tracks how many directory entries point to it, could go negative (underflow). That’s a major red flag, indicating a logic error.

The kernel panicked with a warning like

WARNING: CPU: 1 PID: 5824 at fs/inode.c:407 drop_nlink+xc4/x110 fs/inode.c:407
...
Call Trace:
  nilfs_rmdir+x1b/x250 fs/nilfs2/namei.c:342
  vfs_rmdir+x3a3/x510 fs/namei.c:4394
  do_rmdir+x3b5/x580 fs/namei.c:4453
  ...

Here’s a simplified example of the relevant code logic (before the fix)

struct inode *nilfs_iget(struct super_block *sb, unsigned long ino) {
    // ...get inode from cache or disk...
    // At this point, no check for deleted (i_nlink == ) inode
    return inode;
}

This code retrieves an inode structure, but does NOT check whether the inode has been deleted (a deleted inode should have i_nlink == ). As a result, stale or already-removed inodes can be reused, leading to unpredictable and unsafe behavior.

The Fix: Simple, But Effective

The fix adds a crucial check: If the inode looks deleted, reclaim it immediately instead of using it.

Patched code snippet

struct inode *nilfs_iget(struct super_block *sb, unsigned long ino) {
    // ...get inode from cache or disk...
    if (inode->i_nlink == ) {
        iput(inode); // This inode is deleted, don't use it!
        return ERR_PTR(-ESTALE);
    }
    return inode;
}

By checking i_nlink, nilfs2 avoids ever using inodes that were previously deleted, which prevents the whole class of bugs that led to the warning and possible data corruption.

What could an attacker do?

By messing with the nilfs2 inode bitmap, an attacker (or a faulty process) might cause the kernel to assign the same inode number to multiple files or directories. If exploited carefully, this could lead to:

Potential privilege escalation (if a crafted file system tricks kernel code paths)

An attacker with write access to a nilfs2 volume could use a custom image to trigger this bug intentionally.

CAUTION: Don’t run this on a real system.

# 1. Create a corrupted nilfs2 image (e.g., with a custom tool or hex editor)
# 2. Mount the image in Linux
sudo mount -t nilfs2 corrupted.img /mnt/test

# 3. Try to create and then remove directories with could overlap inodes
mkdir /mnt/test/file
rmdir /mnt/test/.nilfs
rmdir /mnt/test/file

Watch the kernel logs (dmesg). On a vulnerable kernel, you might see a WARNING or panic.

- Kernel Patch Commit
- syzkaller bug report
- Relevant discussion on LKML

Conclusion

CVE-2024-53690 is a textbook example of how simple consistency checks protect us from deep file system errors and possible attacks. Thanks to quick detection by syzbot and a straightforward patch, nilfs2 users are safer today.

Timeline

Published on: 01/11/2025 13:15:26 UTC
Last modified on: 05/04/2025 09:56:57 UTC