CVE-2025-71184

What it actually does

NULL pointer dereference in btrfs_evict_inode during early tracing setup that fetches root_objectid before the root-NULL guard check, resulting in a kernel crash.

Why it matters to the business

Systems using the Btrfs filesystem may experience unexpected kernel panics leading to denial of service, requiring reboots and potential data unavailability until the kernel is updated.

How an attack unfolds

An attacker with local access crafts conditions that trigger inode eviction on a Btrfs volume where the root pointer is NULL, causing the dereference during trace setup; the issue is local-only and has not been observed in active campaigns.

How to fix it

Update the Linux kernel to a version containing commit 582ba48e4a4c06fef6bdcf4e57b7b9af660bbd0c or later; rebuild and reboot with the patched kernel.

How to confirm the fix worked

Confirm the running kernel contains commit 582ba48e4a4c06fef6bdcf4e57b7b9af660bbd0c via git describe or kernel version string, then exercise Btrfs inode eviction workloads and verify absence of NULL dereference oops in dmesg.

Typical attack path

1. Obtain local user access on a Linux system using Btrfs
2. Trigger inode eviction paths in btrfs_evict_inode with a NULL root pointer
3. Cause the kernel to dereference the NULL root during tracing initialization
4. Induce a kernel oops or panic

How to detect it

Review kernel logs (dmesg, /var/log/kern.log) for NULL pointer dereference oops mentioning btrfs_evict_inode or root_objectid; correlate with Btrfs inode eviction events around the crash timestamp.

• btrfs_evict_inode
• root_objectid
• NULL dereference

What your security team should do

• Prioritize kernel upgrade on all Btrfs-using systems within standard change windows
• Monitor EPSS trend and reassess if exploit code appears
• Add Btrfs-specific crash signatures to kernel log monitoring rules