CVE-2025-39884

What it actually does

Race condition in btrfs inode eviction and caching allows a live btrfs_inode to be removed from root->inodes xarray via __xa_erase after a concurrent btrfs_iget recreates it, leading to premature btrfs_add_dead_root calls and infinite loops in btrfs_kill_all_delayed_nodes during subvolume deletion.

Why it matters to the business

Systems using btrfs subvolumes may experience soft lockups and unresponsiveness during normal volume deletion operations, disrupting storage management and requiring reboots or memory pressure to recover.

How an attack unfolds

An attacker with local access performs concurrent file operations that trigger inode eviction while btrfs_iget is called for the same inode; once the xarray entry is lost, triggering subvolume deletion causes the delayed_nodes xarray to never empty, resulting in a live lock.

How to fix it

Update the Linux kernel to a version containing commit 9ba898c9fcbe6ebb88bcd4df8aab0f90090d202e or later; apply the __xa_cmpxchg fix in btrfs_del_inode_from_root.

How to confirm the fix worked

Confirm kernel version includes the referenced commit; reproduce subvolume deletion under inode eviction load and verify no soft lockups occur.

Typical attack path

1. Obtain local unprivileged access on a btrfs filesystem
2. Trigger inode eviction via remove_inode_hash while btrfs_iget_path runs
3. Initiate subvolume deletion that reaches btrfs_clean_one_deleted_snapshot
4. Observe soft lockup in btrfs_kill_all_delayed_nodes

How to detect it

Review kernel logs for soft lockup traces mentioning btrfs_kill_all_delayed_nodes or btrfs_clean_one_deleted_snapshot; correlate with subvolume deletion activity.

What your security team should do

• Prioritize kernel upgrades on all btrfs-using systems within maintenance windows
• Monitor for soft lockup reports in dmesg related to btrfs delayed nodes
• Test subvolume deletion workloads after patching