CVE-2025-71183: Linux Kernel Privilege Escalation Flaw

CVE-2025-71183 Overview

A vulnerability has been identified in the Linux kernel's Btrfs filesystem implementation where conflicting inodes are not properly detected when logging inode references. This flaw occurs during rename exchange operations involving directories, potentially leading to filesystem corruption and mount failures following a power failure.

The vulnerability stems from improper handling of inode logging during directory rename operations. When two inodes are exchanged (via rename exchange or multiple non-atomic rename steps) and at least one is a directory, the log tree may only contain one of the inodes. After a power failure, log replay attempts to delete an inode that was never deleted, causing transaction aborts and mount failures.

Critical Impact
Systems using Btrfs filesystems with subvolumes may experience mount failures and potential data loss following unexpected power failures after rename operations.

Affected Products

Linux kernel Btrfs filesystem implementation
Linux kernel versions containing the affected copy_inode_items_to_log() and btrfs_log_new_name() functions
Systems using Btrfs with subvolumes and directory rename operations

Discovery Timeline

2026-01-31 - CVE CVE-2025-71183 published to NVD
2026-02-03 - Last updated in NVD database

Technical Details for CVE-2025-71183

Vulnerability Analysis

The vulnerability resides in the Btrfs logging subsystem's handling of inode references during rename exchange operations. When directories are renamed or exchanged, the btrfs_log_new_name() function is called for both involved inodes. However, because the inodes are directories, their last_unlink_trans field is not updated to the current transaction number.

This creates a problematic scenario: when a subsequent fsync operation triggers parent directory logging via btrfs_log_all_parents(), only one of the exchanged inodes may be logged. The copy_inode_items_to_log() function fails to check for conflicting inodes when the inode's generation is lower than the current transaction (created in a past transaction).

After a power failure, the log replay code encounters an inode with a name that conflicts with another inode in the filesystem tree. The replay attempts to delete the conflicting inode, but when that inode is a directory containing a subvolume, replay_dir_deletes() and btrfs_unlink_inode() are not equipped to handle directory items pointing to root items instead of inode items, resulting in a transaction abort with error code -2 (ENOENT).

Root Cause

The root cause is the missing detection of conflicting inodes in copy_inode_items_to_log() when the source inode has a generation number lower than the current transaction. The code assumes that inodes created in past transactions don't need conflict checking, but this assumption fails when rename exchange operations swap directory positions within the same transaction without updating their last_unlink_trans values.

Additionally, the log replay infrastructure lacks proper handling for directory entries that reference root items (subvolumes) rather than standard inode items, making the deletion attempt fail catastrophically.

Attack Vector

This vulnerability is triggered through normal filesystem operations rather than malicious exploitation. The attack vector involves the following sequence:

Two directories exist under a common parent, with one containing a subvolume
A file in one directory is renamed, updating its last_unlink_trans
A rename exchange swaps the two directories without updating their last_unlink_trans
An fsync on the renamed file triggers partial parent logging
A power failure followed by mount attempt triggers the corrupted log replay

The log replay then fails with a kernel warning at __btrfs_unlink_inode() when attempting to delete a reference to a subvolume, causing the mount operation to fail and the transaction to abort.

Detection Methods for CVE-2025-71183

Indicators of Compromise

Btrfs mount failures following unexpected system shutdowns or power losses
Kernel log messages containing "failed to delete reference to subvol" errors
Transaction abort errors with code -2 (ENOENT) during log-tree replay
Stack traces referencing __btrfs_unlink_inode at offset 0x416/0x440 in the btrfs module

Detection Strategies

Monitor kernel logs for "BTRFS critical" messages during mount operations
Watch for "Transaction aborted (error -2)" messages related to Btrfs operations
Alert on mount failures for Btrfs filesystems after system restarts
Implement kernel log monitoring for warnings at fs/btrfs/inode.c line 4345

Monitoring Recommendations

Enable comprehensive kernel logging for Btrfs filesystem events
Implement automated filesystem health checks after unexpected shutdowns
Monitor for repeated mount failures on Btrfs volumes containing subvolumes
Set up alerts for btrfs tree-log replay errors in system logs

How to Mitigate CVE-2025-71183

Immediate Actions Required

Apply kernel patches from the stable kernel tree as soon as available
Consider temporarily disabling Btrfs log replay if mount failures occur (recovery mode)
Perform regular backups of Btrfs filesystems, especially those containing subvolumes
Ensure systems have proper power protection to reduce unexpected shutdown risks

Patch Information

The Linux kernel maintainers have released patches to address this vulnerability. The fix ensures that conflicting inodes are always detected when logging inode references, regardless of the inode's generation relative to the current transaction. Multiple patch commits are available in the stable kernel tree:

Workarounds

Avoid performing rename exchange operations on directories containing subvolumes until patched
Use sync commands after critical rename operations to ensure data persistence
Consider using alternative filesystems for workloads requiring frequent directory renames with subvolumes
Implement UPS or battery backup to reduce risk of power failure during filesystem operations

bash

# Verify current kernel version and check for available updates
uname -r
# Check for btrfs mount issues in kernel logs
dmesg | grep -i "btrfs.*failed\|btrfs.*abort"
# Force sync after rename operations as a temporary mitigation
sync && sync