CVE-2025-71194: Linux Kernel Race Condition Vulnerability

CVE-2025-71194 Overview

A deadlock vulnerability has been identified in the Linux kernel's Btrfs filesystem implementation. The issue exists in the wait_current_trans() function which is called during start_transaction(). The function incorrectly waits for blocked transactions without considering whether the given transaction type actually needs to wait for that particular transaction state, leading to potential deadlock conditions.

Critical Impact

This vulnerability can cause system deadlocks in Btrfs filesystem operations, potentially leading to system hangs and denial of service conditions when processing ordered extents during transaction commits.

Affected Products

• Linux Kernel (Btrfs filesystem component)
• Systems utilizing Btrfs filesystem with ordered extent operations
• Linux distributions with affected kernel versions

Discovery Timeline

• February 4, 2026 - CVE-2025-71194 published to NVD
• February 5, 2026 - Last updated in NVD database

Technical Details for CVE-2025-71194

Vulnerability Analysis

The vulnerability stems from a race condition in the Btrfs transaction handling mechanism. The btrfs_blocked_trans_types[] array defines which transaction types should wait for which transaction states, but this check was missing in the wait_current_trans() function. This oversight creates a scenario where transaction types that should be allowed to join during certain blocked states are forced to wait unnecessarily.

The deadlock manifests through a specific sequence of events involving two transactions and pending ordered extents. When Transaction A enters TRANS_STATE_COMMIT_DOING state, a worker processing an ordered extent calls start_transaction() with TRANS_JOIN. The join_transaction() function returns -EBUSY because of the ongoing commit. After Transaction A completes and a new Transaction B is created, the ordered extent gets added to Transaction B's pending list. When Transaction B begins its commit and enters TRANS_STATE_COMMIT_START, the original worker reaches wait_current_trans() and waits unconditionally for Transaction B, even though TRANS_JOIN should not wait for TRANS_STATE_COMMIT_START according to the defined transaction type rules.

Root Cause

The root cause is a missing validation check in wait_current_trans() that should have consulted the btrfs_blocked_trans_types[cur_trans->state] array against the given transaction type before deciding to wait. Without this check, all transaction types wait unconditionally for blocked transaction states, creating the conditions for a circular wait pattern that results in deadlock.

Attack Vector

This is a local denial of service vulnerability that can be triggered through normal filesystem operations involving Btrfs ordered extents. The deadlock occurs when:

1. A transaction is in the commit process (TRANS_STATE_COMMIT_DOING)
2. An ordered extent worker attempts to join a transaction (TRANS_JOIN)
3. The original transaction completes and a new transaction starts
4. The new transaction begins committing while the worker is still waiting
5. The new transaction waits for the ordered extent to complete
6. The ordered extent worker waits for the transaction to unblock

This creates a circular dependency where Transaction B waits for the ordered extent completion, while the ordered extent processing waits for Transaction B, resulting in a system deadlock. The call stacks show the bstore_kv_sync task in btrfs_commit_transaction waiting for ordered extents while the kworker task in wait_current_trans waits for the transaction commit to complete.

Detection Methods for CVE-2025-71194

Indicators of Compromise

• System hangs or freezes during Btrfs filesystem operations
• Processes stuck in uninterruptible sleep state (D state) related to Btrfs operations
• Kernel logs showing btrfs_commit_transaction and wait_current_trans in call stacks
• High load averages with minimal CPU utilization indicating blocked processes

Detection Strategies

• Monitor for hung task warnings in kernel logs related to Btrfs modules
• Implement process state monitoring for tasks in uninterruptible sleep states exceeding normal thresholds
• Track Btrfs transaction commit times for abnormal delays
• Use kernel debugging tools like crash or kdump to analyze deadlock states

Monitoring Recommendations

• Enable hung task detection in the kernel (CONFIG_DETECT_HUNG_TASK)
• Configure appropriate hung task timeout warnings
• Monitor /proc/sys/kernel/hung_task_timeout_secs for detection
• Set up alerting for Btrfs-related kernel warnings and errors

How to Mitigate CVE-2025-71194

Immediate Actions Required

• Update to a patched Linux kernel version containing the fix
• Consider using alternative filesystems (ext4, XFS) for critical workloads until patching is complete
• Monitor systems for signs of deadlock conditions
• Plan maintenance windows for kernel updates on production systems

Patch Information

The fix involves passing the transaction type to wait_current_trans() and checking btrfs_blocked_trans_types[cur_trans->state] against the given type before deciding to wait. This ensures that transaction types which are allowed to join during certain blocked states will not unnecessarily wait and cause deadlocks.

Patches are available through the following Linux kernel stable commits:

• Commit 5037b342825d
• Commit 8b0bb145d3bc
• Commit 99da896614d1
• Commit 9ac63333d600

Workarounds

• Reduce Btrfs filesystem load during peak operations to minimize deadlock probability
• Implement monitoring and automatic detection of hung Btrfs processes
• Consider scheduling fsync-heavy workloads to avoid concurrent transaction stress
• Use watchdog mechanisms to detect and recover from potential deadlock situations

# Check current kernel version for Btrfs module
uname -r
modinfo btrfs | grep version

# Monitor for hung tasks related to Btrfs
dmesg | grep -i "hung_task\|btrfs"

# Check for processes stuck in uninterruptible sleep
ps aux | awk '$8=="D" {print}'