CVE-2024-23850

What it actually does

Race condition in btrfs_get_root_ref allows a subvolume to be read before its root item is fully initialized, triggering an assertion failure and kernel crash.

Why it matters to the business

Local users on affected Linux systems using Btrfs can cause unexpected kernel panics, resulting in system instability, service outages, and potential data loss during recovery.

How an attack unfolds

An attacker with local access creates a subvolume while simultaneously triggering concurrent reads of the root item, hitting the window where the item exists but the subvolume is not yet ready, forcing the assertion failure.

How to fix it

Upgrade the Linux kernel to a version newer than 6.7.1 that contains the fix for the btrfs root item initialization race; apply vendor-supplied kernel updates as soon as available.

How to confirm the fix worked

Verify the running kernel version exceeds 6.7.1; attempt to reproduce subvolume creation under concurrent load in a test environment and confirm absence of the assertion failure in dmesg or kernel logs.

Typical attack path

1. Obtain local user access on a Btrfs-enabled system
2. Issue subvolume creation via btrfs ioctl or command
3. Race with concurrent filesystem operations that read the new root item
4. Trigger assertion failure in btrfs_get_root_ref leading to crash

How to detect it

Review kernel logs and dmesg for btrfs assertion failures or crashes referencing disk-io.c and root item insertion; correlate with recent subvolume creation activity by local users.

• btrfs_get_root_ref
• assertion failure.*subvolume
• disk-io.c.*root item

What your security team should do

• Prioritize kernel updates for all Btrfs-using systems within standard change windows
• Restrict local user access on systems where Btrfs is enabled until patched
• Monitor kernel crash reports for Btrfs-related assertions
• Test patched kernels in staging before broad deployment