CVE-2025-71183
Linux Kernel vulnerability analysis and mitigation

Overview

CVE-2025-71183 is a denial-of-service vulnerability in the Linux kernel's btrfs filesystem inode logging mechanism, specifically in how it handles rename exchange operations on directories containing subvolumes. When two directories are exchanged via rename operations and at least one contains a subvolume, the log tree can enter an incorrect state. After an unclean shutdown or power failure, the log replay code incorrectly attempts to delete an inode that was never deleted, causing a transaction abort and mount failure. The vulnerability affects Linux kernel versions from approximately 3.18.32 through 6.18.5 (with specific version ranges), and has a CVSS v3.1 base score of 5.5 (Medium) (Red Hat Advisory, Red Hat Bugzilla).

Technical details

The root cause is a logic flaw (CWE-667: Improper Locking / incorrect state management) in btrfs_log_new_name() within the btrfs inode logging path. When a rename exchange is performed on two directories (inodes A and B), their last_unlink_trans fields are not updated because they are directories. A subsequent fsync of a file under one of those directories causes only one directory's inode to be logged, leaving the other directory's inode absent from the log tree. During log replay after a power failure, the replay code finds a name conflict and attempts to delete the non-logged directory inode — but if that directory contains a subvolume, replay_dir_deletes() and btrfs_unlink_inode() cannot handle directory entries pointing to root items (subvolumes) rather than regular inode items, resulting in a transaction abort with the error "failed to delete reference to subvol" (Red Hat Bugzilla). The fix ensures conflicting inodes are always detected and logged during inode ref logging, regardless of the inode's generation relative to the current transaction.

Impact

Successful triggering of this vulnerability results in complete inaccessibility of the affected btrfs filesystem after an unclean shutdown. The filesystem mount fails with a transaction abort, rendering all data on the affected volume unavailable until the issue is resolved. There is no confidentiality or integrity impact — the vulnerability is purely an availability (denial of service) issue affecting local systems using btrfs with subvolumes (Red Hat Advisory, Red Hat Bugzilla).

Exploitation steps

  1. Precondition Setup: Ensure the target system uses a btrfs filesystem with at least two directories (dir1, dir2) under the same parent, where dir2 contains a btrfs subvolume, and a file exists under dir1. All must be persisted in a prior transaction.
  2. Trigger last_unlink_trans update: Rename the file under dir1 to update its last_unlink_trans to the current transaction N.
  3. Perform rename exchange: Execute a rename exchange operation (e.g., using renameat2 with RENAME_EXCHANGE flag) swapping dir1 and dir2, causing btrfs_log_new_name() to be called for both directory inodes without updating their last_unlink_trans.
  4. Force fsync: Perform an fsync on the renamed file, which triggers logging of its parent directory (one of the exchanged directories) but not the other, leaving the log tree in an inconsistent state.
  5. Force unclean shutdown: Trigger a power failure or abrupt system shutdown (e.g., echo b > /proc/sysrq-trigger) before a full transaction commit.
  6. Observe mount failure: On reboot, the btrfs log replay attempts to delete the non-logged directory inode, fails with "failed to delete reference to subvol", aborts the transaction, and the filesystem becomes unmountable (Red Hat Bugzilla).

Indicators of compromise

  • Logs: Kernel log messages containing BTRFS critical (device <X>): failed to delete reference to subvol during mount/log replay; BTRFS: Transaction aborted (error -2) in dmesg or /var/log/kern.log.
  • Logs: Kernel warning stack trace referencing __btrfs_unlink_inode+0x416/0x440 [btrfs] in dmesg output during mount attempts.
  • Logs: Mount failure messages for btrfs volumes following an unclean shutdown, particularly on systems with btrfs subvolumes.
  • File System: Btrfs filesystem that cannot be mounted after a power failure or abrupt shutdown, with the log replay phase failing (Red Hat Bugzilla).

Mitigation and workarounds

Update the Linux kernel to a patched version: 6.1.161 or later, 6.6.121 or later, 6.12.66 or later, or 6.18.6 or later. Patches are available via upstream kernel commits: 0c2413c69129, 7ba0b6461bc4, a63998cd6687, c7f0207db68d, and d52af58dd463. Distribution-specific updates are available from Ubuntu (USN-8278-1, USN-8289-1, USN-8296-1, USN-8278-2, USN-8296-2), SUSE (SUSE-SU-2026:2217-1, SUSE-SU-2026:2238-1), and Oracle Enterprise Linux. As a workaround on unpatched systems, avoid performing rename exchange operations on btrfs directories that contain subvolumes, and ensure clean system shutdowns to prevent log replay scenarios (Red Hat Advisory, Red Hat Bugzilla).

Additional resources


SourceThis report was generated using AI

Related Linux Kernel vulnerabilities:

CVE ID

Severity

Score

Technologies

Component name

CISA KEV exploit

Has fix

Published date

CVE-2026-64557NONEN/A
  • Linux Kernel logoLinux Kernel
  • kernel-rt-selftests-internal
NoNoJul 29, 2026
CVE-2026-64556NONEN/A
  • Linux Kernel logoLinux Kernel
  • kernel-64k-devel
NoNoJul 29, 2026
CVE-2026-64555NONEN/A
  • Linux Kernel logoLinux Kernel
  • linux-azure-fde-6.14
NoNoJul 27, 2026
CVE-2026-64554NONEN/A
  • Linux Kernel logoLinux Kernel
  • linux-gcp-6.14
NoYesJul 27, 2026
CVE-2026-64553NONEN/A
  • Linux Kernel logoLinux Kernel
  • kernel-rt-64k-debug-modules-internal
NoYesJul 27, 2026

Free Vulnerability Assessment

Benchmark your Cloud Security Posture

Evaluate your cloud security practices across 9 security domains to benchmark your risk level and identify gaps in your defenses.

Request assessment

Get a personalized demo

Ready to see Wiz in action?

"Best User Experience I have ever seen, provides full visibility to cloud workloads."
David EstlickCISO
"Wiz provides a single pane of glass to see what is going on in our cloud environments."
Adam FletcherChief Security Officer
"We know that if Wiz identifies something as critical, it actually is."
Greg PoniatowskiHead of Threat and Vulnerability Management