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:

1. An existing directory "dir1" exists under parent directory inode A
2. The directory "dir1" is moved to a different parent directory
3. A new file is created with the name "dir1" in the original parent directory (inode A)
4. When the new file is fsynced, the logging mechanism incorrectly logs both the new file's inode and the moved directory's inode reference
5. Additional file operations and fsync calls persist these conflicting log entries
6. 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

# 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"