CVE-2025-68778: Linux Kernel Privilege Escalation

CVE-2025-68778 Overview

A vulnerability has been discovered in the Linux kernel's btrfs filesystem subsystem related to improper handling of directory inodes during transaction logging. The flaw occurs when a directory is moved from one parent directory to another within the same transaction, and a conflicting inode with the same name is created. This can lead to filesystem corruption during log replay after a power failure, resulting in directories appearing to have two hard links.

Critical Impact
This vulnerability can cause filesystem corruption and mount failures following unexpected power loss, potentially leading to data loss or system unavailability on systems using the btrfs filesystem.

Affected Products

Linux Kernel (btrfs filesystem subsystem)
Systems utilizing btrfs with transaction logging enabled

Discovery Timeline

2026-01-13 - CVE CVE-2025-68778 published to NVD
2026-01-13 - Last updated in NVD database

Technical Details for CVE-2025-68778

Vulnerability Analysis

The vulnerability resides in the btrfs filesystem's transaction logging mechanism, specifically in how it handles conflicting inodes when a directory has been moved within the current transaction. The issue manifests through a specific sequence of filesystem operations:

An existing directory "dir1" exists under parent directory inode A
The directory "dir1" is moved to a different parent directory
A new file is created with the name "dir1" in the original parent directory (inode A)
When the new file is fsynced, the logging mechanism incorrectly logs both the new file's inode and the moved directory's inode reference
Additional file operations and fsync calls persist these conflicting log entries
Upon power failure and subsequent mount, log replay processes the directory inode and adds a new hard link without removing the old one

This results in a directory with an invalid hard link count of 2, which violates btrfs's filesystem integrity constraints and triggers a mount failure during tree checking.

Root Cause

The root cause lies in the btrfs_log_new_name() function and related logging code paths that fail to properly handle the case where a conflicting inode is a directory that was moved in the current transaction. The logging mechanism incorrectly assumes it can safely log the moved directory's new INODE_REF without considering that the old parent directory reference may not have been logged, leading to orphaned hard link references during replay.

Attack Vector

This vulnerability is triggered through a specific sequence of local filesystem operations on a btrfs-mounted volume. While not remotely exploitable, the conditions can occur during normal filesystem usage patterns involving directory moves, file creation with reused names, and fsync operations. Power failures or system crashes during this state will trigger the corruption during the next mount's log replay phase.

The vulnerability mechanism involves btrfs's write-ahead logging system where:

Directory move operations update inode references in the log tree
New file creation with conflicting names creates additional log entries
The btrfs_log_new_name() function updates log tree entries in memory
Subsequent fsync persists these entries without proper conflict resolution
Log replay fails to remove stale directory links, resulting in a directory with nlink=2 which is invalid for directories (they should have nlink=1 plus child count)

Detection Methods for CVE-2025-68778

Indicators of Compromise

Kernel log messages containing "corrupt leaf" errors related to btrfs
Error messages indicating "invalid nlink: has 2 expect no more than 1 for dir"
Mount failures on btrfs filesystems after unexpected system shutdowns
dmesg output showing btrfs tree-log replay errors with inode reference conflicts

Detection Strategies

Monitor system logs for btrfs-related corruption messages during boot or mount operations
Implement automated alerting for kernel messages containing "BTRFS critical" severity entries
Run periodic btrfs check commands on mounted filesystems to detect early signs of corruption
Track systems that have experienced unexpected power loss for subsequent mount issues

Monitoring Recommendations

Configure log aggregation to capture and alert on btrfs filesystem error patterns
Implement monitoring for system boot failures related to filesystem mounts
Deploy health checks that verify btrfs filesystem integrity on critical systems
Monitor for kernel messages referencing log replay failures on btrfs volumes

How to Mitigate CVE-2025-68778

Immediate Actions Required

Apply the latest Linux kernel patches that address this btrfs logging issue
Consider using synchronous mount options on critical btrfs volumes to reduce log replay scenarios
Implement UPS or power protection on systems with critical btrfs filesystems to minimize power failure risk
Review and backup data on btrfs volumes before applying kernel updates

Patch Information

Multiple patches have been released to address this vulnerability in the Linux kernel. The fixes ensure that conflicting inodes that are directories moved in the current transaction are not incorrectly logged, preventing the dual hard link condition during log replay. The following kernel patches are available:

Linux Kernel Patch - Commit 266273eaf4d9
Linux Kernel Commit - Commit 7359e1d39c78
Linux Kernel Update - Commit a35788ddf8df
Linux Kernel Change - Commit d478f50727c3
Linux Kernel Revision - Commit d64f3834dffe

Update to a kernel version containing these patches to remediate the vulnerability.

Workarounds

If patching is not immediately possible, consider remounting btrfs filesystems with -o noatime,nodatasum options to reduce write activity patterns that trigger the issue
Avoid performing directory move operations followed by file creation with the same name in rapid succession
Implement filesystem-level snapshots before performing complex directory restructuring operations
Consider temporarily using alternative filesystems (ext4, xfs) for workloads involving frequent directory moves until patches can be applied

bash

# Check current kernel version and btrfs module status
uname -r
modinfo btrfs | grep version

# Verify btrfs filesystem integrity
btrfs check --readonly /dev/sdXn

# Check for btrfs-related errors in system logs
dmesg | grep -i btrfs
journalctl -k | grep -i "btrfs critical"