CVE-2024-46781 - Deep Dive into a Linux Kernel nilfs2 Log Recovery Use-After-Free Vulnerability

The Linux kernel is at the core of most Linux-based systems, trusted by millions worldwide. Occasionally, vulnerabilities are discovered that can impact stability and security. One recently patched issue is CVE-2024-46781, found in the nilfs2 filesystem, which could lead to a use-after-free bug during mount-time log recovery. This article breaks down the vulnerability, its cause, exploitation details, and resolution—in simple language, with original references and code snippets.

What is CVE-2024-46781?

CVE-2024-46781 is a vulnerability in the Linux kernel, specifically within the nilfs2 filesystem. The issue was discovered through error injection testing: when recovering file system data using logs created by "dsync" writes (a special method of making file changes persistent), if an error happened before a recovered checkpoint could be written, certain in-memory structures (inodes) were not cleaned up. This left stale pointers in the kernel, causing a use-after-free condition, which is a serious memory error.

nilfs2 and its Recovery Mechanism

nilfs2 is a log-structured file system for Linux, designed for continuous snapshotting, crash recovery, and performance. During mount, if there were uncommitted changes (e.g., after a sudden system shutdown), nilfs2 will replay its logs to restore the file system to a consistent state. This process is called recovery.

And an error occurs before the new checkpoint is fully written

- The inodes with recovered data remain in the ns_dirty_files list inside the nilfs object, not released back to memory

Error Discovery

The bug was found with KASAN (Kernel Address Sanitizer), a tool that detects memory errors like use-after-free in the Linux kernel.

How the Exploit Works

While this vulnerability requires specific conditions and is unlikely to be exploited remotely, understanding how it could be triggered is important:

Simulate a crash before a checkpoint is fully restored (for example, by forcibly powering off).

4. Inject an error BEFORE the log writer can create a recovered checkpoint during recovery on remount.

Observe: The inodes with recovered data stay in the kernel's ns_dirty_files list.

6. Next access to those freed inodes might corrupt memory or cause undefined system behavior (potential privilege escalation or denial of service).

Below is a simplified version representing the core issue

if (error) {
    // ERROR OCCURS HERE
    // inodes in ns_dirty_files are not freed!
    return error;
}

The linked list ns_dirty_files tracks modified inodes during recovery. If the cleanup (nilfs_dispose_dirty_files) is not called on error, these entries remain, leading to use-after-free.

The fix ensures that, upon error, all inodes read during recovery are properly cleaned up

if (error) {
    nilfs_dispose_dirty_files(nilfs, 1); // <--- FIX: Clean up!
    return error;
}

This way, no stale pointers are left, and memory remains consistent and safe.

CVE Record:

NVD Entry for CVE-2024-46781

Kernel Patch Commit:

kernel/git/torvalds/linux.git - fs/nilfs2/recovery.c patch

Nilfs2 Filesystem:

Nilfs2 Project
- KASAN Documentation

Exploit Details—Why It Matters

While this bug requires local filesystem access and specific timing, use-after-free errors are highly dangerous:

Accidental triggers might make your system unstable, cause file corruption, or crashes

- Even if remote exploitation is unlikely, malware or untrusted users with local access could leverage this

Responsible Disclosure and Update:
The issue was responsibly patched by Linux maintainers once discovered. Always ensure that your kernel is up-to-date, especially if you use nilfs2 or allow untrusted users to mount filesystems.

TL;DR

- CVE-2024-46781 is a use-after-free bug in the Linux kernel's nilfs2 filesystem recovery code, triggered by complex log replay scenarios with error injection.

Keep your system updated—especially if it uses nilfs2.

- For more, check out the commit patch.

Timeline

Published on: 09/18/2024 08:15:05 UTC
Last modified on: 11/05/2024 09:46:31 UTC