In early 2024, a significant vulnerability was identified and fixed in the Linux kernel’s Btrfs filesystem (“zoned” mode). The flaw, tracked as CVE-2024-26944, was uncovered by Shinichiro and quickly resolved by kernel maintainers. Here’s what happened, how it could be exploited, and a look at the remediated code—a resource for sysadmins and researchers looking to deeply understand this bug.

What is CVE-2024-26944?

Short version:
A use-after-free (UAF) memory bug in the Linux kernel’s Btrfs “zoned” block device support. When running specific device replace operations, the Btrfs code could access freed memory, leading to possible crashes, privilege escalation, or in rare cases, remote code execution (RCE).

Affected:
Linux kernel >= 5.15 (with zoned block device support enabled for Btrfs).

Severity:
High – exploits could impact system stability or security.

Device Replace Initiated:

The admin starts a device replacement operation (for example, for swapping out a faulty disk). Btrfs shuffles data from the old device to a new one.

Cleaner Thread Runs:

Separately, the background kernel thread responsible for cleaning up unused block groups (cleaner_kthread) calls:

`


The result: do_zone_finish() can access a memory area that has already been released—this is the classic use-after-free.

The following Kernel Address Sanitizer (KASAN) log illustrates the invalid access

BUG: KASAN: slab-use-after-free in do_zone_finish+x91a/xb90 [btrfs]
Read of size 8 at addr ffff8881543c806 by task btrfs-cleaner/3494007
...
The buggy address belongs to the object at ffff8881543c800
which belongs to the cache kmalloc-1k of size 1024
...
Memory state around the buggy address:
>ffff8881543c800: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb

This means the kernel’s background task tried to use already-released memory.

Here’s a simplistic outline (pseudocode) of where the trouble hit

// called by cleaner thread
void do_zone_finish(struct btrfs_device *device) {
    // ... assumption: device is still valid
    if (device->zone_info) {    // CRASH! device may be freed
        // process zone finishing
    }
}

Once another thread (the device replacer) freed device, any access to device->zone_info became unsafe.

The Fix

The solution was to ensure device structures cannot be freed while still being referenced, by refcounting or invalidating them appropriately. Put simply, you must not touch pointers to devices after they may have been freed:

// Improved: ensure device is valid before use
void do_zone_finish(struct btrfs_device *device) {
    if (!device || !device->zone_info)
        return;
    // Safe to proceed now!
}

Or, more robustly, by controlling device lifetime via kernel refcounts.

Potential Exploit Example

An attacker with a local account (able to access and manipulate block devices directly—for example, using ioctl or specialized tools) could:

Simultaneously cause blocks to be cleaned up, forcing the race.

3. Get the kernel to dereference the freed memory, leading to a crash (DoS), or in extreme, specially crafted cases, escalate privileges (if they can guess/control freed memory).

Exploit window is small but real, especially on shared or automated environments (VM hosts, public clouds, appliances, etc.).

Update Your Kernel:

If you run Btrfs on zoned devices, update to any kernel with btrfs: zoned: fix use-after-free in do_zone_finish() (see references for patches).

References & Further Reading

- Original Linux kernel commit – Patch details.
- Kernel.org CVE page for CVE-2024-26944
- Btrfs Zoned Devices Documentation
- FSTests btrfs/070 script – How the issue was triggered in test suites.
- KASAN: Kernel AddressSanitizer

Conclusion

CVE-2024-26944 is a classic example of the sort of race condition and memory management hazards that crop up with complex C code, especially in filesystems like Btrfs. If you’re a Linux admin or developer, keep your kernels updated and never assume background threads won’t collide on device state!
For system defenders, now’s a great time to review any kernel version handling Btrfs on zoned devices and patch accordingly.

*Stay safe, and happy hacking!*

Author’s Note:
This deep-dive was crafted in simple, direct language for readers seeking a clear understanding of CVE-2024-26944, with both technical and practical details not found side-by-side in other sources. Please report any new findings or real-world exploits responsibly to the upstream kernel maintainers.

Timeline

Published on: 05/01/2024 06:15:10 UTC
Last modified on: 01/14/2025 14:29:21 UTC