CVE-2024-56774 is a newly identified vulnerability found in the Linux kernel's Btrfs (B-tree File System) implementation, specifically in the btrfs_search_slot() function. This bug was discovered through fuzz testing by Syzbot and involves a classic null pointer dereference problem.

If exploited, this vulnerability can lead to kernel crashes (DoS) and potentially impact system stability. The issue affects users working with corrupted Btrfs filesystems and advanced options like rescue=ibadroots. Fortunately, a fix was published, adding a simple but crucial sanity check to prevent this crash from happening in the first place.

This article breaks down the vulnerability, demonstrates how the bug works, and provides insight into the fix applied.

What is the Bug?

When the Btrfs filesystem’s extent tree root is corrupted, the extent tree pointer can become NULL. Certain recovery scenarios (e.g., using rescue=ibadroots) provoke this exact situation.

The vulnerable function, btrfs_search_slot(), did not check whether the root pointer was NULL before operating on it, which would result in a null pointer dereference and a kernel panic.

Problematic Code (Before the Fix)

int btrfs_search_slot(struct btrfs_trans_handle *trans,
                      struct btrfs_root *root,
                      const struct btrfs_key *key,
                      struct btrfs_path *p,
                      int ins_len, int cow)
{
    // ... no check for root == NULL ...
    struct extent_buffer *eb = root->node; // crash if root is NULL
    // ... rest of the code ...
}

If root is NULL (which happens during certain corrupt states), the above line would access a member of a NULL pointer, causing a crash.


### Exploit/Crash Reproduction

Syzbot, an automated Linux kernel fuzzer, discovered this flaw while testing Btrfs. A simple reproduction case involves:

Simplified Proof-of-Concept (For Educational Purposes)

Warning: Do not use on production systems—may corrupt data.

# Make test image and corrupt it (do as root)
truncate -s 128M test.img
mkfs.btrfs test.img
# Corrupt extent root (this is just illustrative - actual corruption is trickier)
dd if=/dev/zero of=test.img bs=4K seek=16 count=1

# Mount in rescue mode
mount -o loop,rescue=ibadroots test.img /mnt/test

# Trigger scrub (assumes btrfs-progs installed)
btrfs scrub start /mnt/test
# Kernel panic occurs!

The kernel will now panic due to the unprotected NULL dereference in btrfs_search_slot().

The fix adds a quick check to ensure the root pointer is not NULL before operating on it

int btrfs_search_slot(struct btrfs_trans_handle *trans,
                      struct btrfs_root *root,
                      const struct btrfs_key *key,
                      struct btrfs_path *p,
                      int ins_len, int cow)
{
    if (!root)    // <--- The crucial fix
        return -EINVAL;

    // Rest of the original function...
}

Now, if something tries to call btrfs_search_slot() with a NULL root, it just returns an error instead of crashing the kernel.

Who is affected?

Any Linux user with a system using Btrfs, especially those running recovery or scrub operations on damaged filesystems.

Exploitability:

This bug is a _denial of service_ condition. While it's not remotely exploitable, it could be abused by anyone who has write access to a Btrfs volume, corrupting the root to intentionally trigger a system crash.

Severity:

Medium. Fortunately, this bug does not allow privilege escalation or data reading—it only causes a DoS.

References

- Kernel commit: Add a sanity check for btrfs root in btrfs_search_slot()
- Syzbot report (mailing list)
- Btrfs Wiki
- btrfs_search_slot() in Kernel source

Conclusion

CVE-2024-56774 is a powerful reminder that even simple missing sanity checks in system software can cause critical failures. With the latest patch, Linux systems running Btrfs are protected from opportunistic crashes due to null pointer dereference in recovery scenarios.

If you use Btrfs or run servers with recovery operations, make sure your kernel includes this fix.

*Stay tuned for more clear and exclusive deep-dives on the latest CVEs affecting Linux!*

Timeline

Published on: 01/08/2025 18:15:18 UTC
Last modified on: 01/20/2025 06:27:54 UTC