A race condition deep inside the Btrfs filesystem’s delayed allocation cleanup can bring down Linux hosts with kernel panics, and keep crashing them over and over, until a patched kernel is rolled out. Tracked as CVE-2024-58089, the vulnerability has already been fixed upstream, but unpatched systems—especially those running on aarch64 hardware with 64K memory pages—face an elevated risk of denial-of-service from any local user or untrusted disk image.

How the Crash Unfolds

At the heart of the flaw lies a double‑accounting mistake in how the kernel tracks “ordered extents” while writing data to disk. When Btrfs’s btrfs_run_delalloc_range function encounters an error on a system where the filesystem block size (typically 4 KB) is smaller than the CPU page size (e.g., 64 KB on many ARM servers), the error‑handling code can try to finalize the same ordered extent twice. This corrupts internal bookkeeping, triggering the kernel’s defensive assertion “BTRFS critical: bad ordered extent accounting,” followed by a NULL pointer dereference and eventually a full kernel crash.

Crash traces routinely include calls like extent_writepage, run_delalloc_nocow, and can_finish_ordered_extent. On vulnerable configurations, the entire host can become unusable, with the panic repeating on every reboot if the same storage workload or filesystem image is re‑mounted. The bug was discovered through kernel fuzzing and testing, and confirmed by multiple distribution advisories.

Microsoft’s own vulnerability tracking entry for CVE-2024-58089 lists the same technical narrative and points to the upstream commits that plug the hole.

Which Systems Are at Risk

Any Linux kernel with Btrfs enabled and at least one Btrfs volume mounted is theoretically vulnerable. In practice, the bug is most easily triggered on aarch64 platforms that use 64K pages with 4K filesystem blocks—a combination common on server‑grade ARM chips like Ampere Altra and AWS Graviton. However, x86_64 systems, which normally use 4K pages, are not immune. If a workload or crafted image causes the code path to be hit, a crash can occur regardless of architecture.

The following groups should prioritize this patch:

  • Cloud and virtualisation operators: any host that allows tenants to mount their own disk images or run containers with Btrfs storage backends is a prime target. A single unprivileged user can repeatedly crash the host.
  • Developers and CI pipelines: automated build environments that process or mount Btrfs images could become unstable if an image triggers the race.
  • WSL users on Windows: Windows Subsystem for Linux runs a real Linux kernel; if you have Btrfs tools installed and mount a Btrfs volume inside WSL, you might be affected. Microsoft ships its own Linux kernel for WSL2, so verifying the kernel version and patch status is crucial.
  • Embedded and IoT devices: many routers, NAS boxes, and SoCs ship with a kernel that has Btrfs compiled in. These often lag in receiving updates, making them a long‑term concern.

According to the National Vulnerability Database, the affected kernel versions span at least from Linux 5.0 up to early 6.13‑rc kernels. Distributions have since published updated packages with backports, but administrators must check their specific kernel builds.

A Deeper Look at Btrfs Accounting

Btrfs relies on “ordered extents” to coordinate in‑flight writes, copy‑on‑write operations, and metadata updates. The filesystem defers allocation of data blocks (“delayed allocation” or delalloc) until writeback, then tracks each dirty range with an ordered extent. This ensures that metadata is updated only after the data hits persistent storage.

Under normal operation, when btrfs_run_delalloc_range fails—for instance, due to an out‑of‑space condition—the cleanup logic must correctly account for the ranges that were already partially processed. On larger page‑size systems, a single memory page can contain multiple filesystem blocks, making bookkeeping more complex. The erroneous cleanup path, however, would sometimes “finish” an ordered extent for a subpage folio even though another part of the code had already done so. The resulting mismatch trips a BUG_ON() or WARN_ON() that halts the kernel.

The upstream fix, a few lines of patch, reorganizes the error handling so that ordered extents are always finished exactly once. This minimal change makes backporting to stable trees straightforward, but it still requires a full kernel rebuild and reboot.

How We Got Here

Btrfs has been part of the mainline Linux kernel since 2009 and has grown into a feature‑rich copy‑on‑write filesystem. Its delayed allocation and ordered extent machinery are both a performance boon and a source of infamous stability bugs. Over the years, multiple race conditions and accounting errors have been discovered and fixed—many of them, like CVE‑2024‑58089, only exposed under the stress of parallelism or unusual storage configurations.

The transition to larger page sizes (64K on aarch64, and eventually on x86_64 with 5‑level paging) has surfaced a new class of subpage accounting bugs. As kernel test robots like syzkaller gained the ability to fuzz Btrfs with different page/block size combinations, bugs that had lain dormant for years were finally triggered. CVE‑2024‑58089 is a direct product of that testing.

Patching: Your First Priority

Step 1 – Inventory your Btrfs hosts

Run the following commands to list mounted Btrfs filesystems and check if the btrfs module is loaded:

findmnt -t btrfs
lsmod | grep btrfs

For WSL users, open your Linux distribution and run these inside the virtual machine. Any output means you’re using Btrfs and should patch.

Step 2 – Verify your kernel version

Check the running kernel with uname -r. Then consult your distribution’s security tracker (e.g., Ubuntu’s CVE‑2024‑58089 page, Debian’s security tracker, or Red Hat’s errata) to see whether that version already contains the fix. For WSL, the kernel is managed by Microsoft; run wsl --status to see the kernel version, and check the WSL release notes for CVE mentions.

Step 3 – Apply the patch immediately

For standard Linux distributions, upgrading to the latest kernel package is the fastest route. On Ubuntu, for example:

sudo apt update && sudo apt dist-upgrade
sudo reboot

For RHEL/Oracle Linux, use yum update kernel and reboot. WSL users should ensure the Windows host is fully updated, then run wsl --update from a PowerShell or Command Prompt. Microsoft ships kernel updates through the Microsoft Update Catalog and Windows Update.

Step 4 – If you cannot patch now

In high‑risk environments where a kernel reboot must be scheduled, apply compensating controls:
- Restrict who can mount filesystems: add nosuid,nodev options to Btrfs mounts and limit access with mount namespaces in containers.
- Disable automatic mounting of removable media: block udisks or systemd‑machined from auto‑mounting unknown filesystems.
- Set up monitoring for Btrfs oops messages in dmesg and configure alerting; a single “bad ordered extent accounting” line should trigger an immediate response.

Special Note for Windows Adjacent Users

For systems running WSL2, the kernel is provided by Microsoft and updated independently of the mainline Linux kernel. The MSRC advisory indicates that the fix has been incorporated into the WSL kernel. To apply it, open Windows Update or PowerShell and run:

wsl --update

Then restart your WSL instances with wsl --shutdown and relaunch. Verify the new kernel version inside your distribution.

Azure and cloud VMs running Linux images should follow their distribution’s update channels. If you’re using a Btrfs‑based Azure template (such as certain container-optimized OS images), the cloud provider may already have auto‑updated the kernel; check your image’s release notes.

Watching for Exploitation Attempts

Even after patching, it’s wise to add detection rules for any signs that an attacker tried to exploit the vulnerability before the fix was applied. Log artifacts to search for include:
- Kernel messages containing “BTRFS critical: bad ordered extent accounting”
- Oops traces with functions like can_finish_ordered_extent or btrfs_run_delalloc_range
- Unexplained host reboots coinciding with Btrfs mount activity

Centralized log aggregation platforms (Splunk, ELK, etc.) can be configured to alert on these patterns. For WSL, the Windows Event Log might record a “Kernel-Power” critical event if the entire Windows host crashes, though that is less likely since WSL2 kernel panics usually take down only the virtualized instance, not the host.

Outlook: The Long Tail of Kernel Fixes

The upstream fix for CVE‑2024‑58089 landed quickly, and major distributions have been backporting it into their stable kernels. However, the embedded and IoT ecosystem—routers, NAS devices, and industrial controllers that ship an older Btrfs‑enabled kernel—may never receive the patch. If you manage such devices, check the vendor’s support lifecycle and consider replacing hardware that cannot be updated.

For the wider Linux community, this vulnerability reinforces the importance of ongoing fuzzing efforts, especially for filesystems with ambitious features. It also highlights the growing attack surface created by the shift to larger page sizes; as 64K pages become more common on both ARM and upcoming x86_64 systems, similar subpage bugs could surface elsewhere.

In the near term, ensure every Btrfs‑using system in your fleet gets the patch. The fix is small and the risk of crashes is tangible—a day’s delay could mean a host taken down repeatedly by a malicious disk image.