CVE-2026-23018: Linux Kernel Race Condition Vulnerability

CVE-2026-23018 Overview

A circular lock dependency vulnerability has been identified in the Linux kernel's btrfs filesystem implementation. The issue occurs in the btrfs_read_locked_inode() function, which calls btrfs_init_file_extent_tree() while holding a path with a read locked leaf from a subvolume tree. Since btrfs_init_file_extent_tree() may perform a GFP_KERNEL allocation, this can trigger memory reclaim operations, creating a dangerous circular lock dependency that could lead to system deadlocks.

Critical Impact

This vulnerability can create a circular lock dependency chain between &delayed_node->mutex, btrfs-tree-00, and fs_reclaim, potentially causing kernel deadlocks and system instability on Linux systems using the btrfs filesystem.

Affected Products

• Linux kernel with btrfs filesystem support
• Systems running kernel version 6.18.0 and potentially earlier versions

Discovery Timeline

• 2026-01-31 - CVE CVE-2026-23018 published to NVD
• 2026-02-03 - Last updated in NVD database

Technical Details for CVE-2026-23018

Vulnerability Analysis

This race condition vulnerability exists within the btrfs filesystem's inode handling code. The root issue stems from improper lock ordering during memory allocation operations. When btrfs_read_locked_inode() is invoked, it maintains a read lock on a subvolume tree leaf while subsequently calling btrfs_init_file_extent_tree(). This function can perform kernel memory allocations using GFP_KERNEL flags, which permits the kernel to trigger memory reclaim if system memory is under pressure.

The circular dependency chain manifests as follows: the fs_reclaim lock depends on btrfs-tree-00, which in turn depends on &delayed_node->mutex, creating a complete cycle. When the kernel's kswapd memory reclaim process attempts to acquire &delayed_node->mutex while already holding fs_reclaim, and another CPU holds btrfs-tree-00 while waiting for fs_reclaim, a deadlock scenario becomes possible.

The lockdep subsystem within the Linux kernel detected this unsafe locking pattern, identifying that CPU0 could hold fs_reclaim while CPU1 holds btrfs-tree-00 and attempts to acquire fs_reclaim, while CPU0 simultaneously attempts to acquire &delayed_node->mutex.

Root Cause

The vulnerability originates from failing to release the btrfs tree path before calling btrfs_init_file_extent_tree(). The function call sequence during operations like btrfs_iget(), btrfs_lookup_dentry(), and btrfs_lookup() maintains locks across allocation boundaries. The __kmalloc_cache_noprof() allocation within btrfs_init_file_extent_tree() can invoke fs_reclaim_acquire(), which conflicts with locks held during btrfs tree operations and delayed node mutex operations in the eviction path.

Attack Vector

This is a local denial of service vulnerability that can be triggered through normal filesystem operations on btrfs volumes. The attack vector involves scenarios where memory pressure coincides with btrfs inode operations, particularly during file lookups and opens. While the vulnerability requires local access and specific timing conditions, it could potentially be triggered by:

• Performing rapid file operations on btrfs filesystems during memory-constrained conditions
• Running workloads that stress both memory and btrfs filesystem operations simultaneously
• Triggering fsync operations while the system is performing memory reclaim

The lockdep warning was triggered during a path_openat() syscall chain, indicating that standard file open operations can expose this vulnerability.

Detection Methods for CVE-2026-23018

Indicators of Compromise

• Kernel log messages containing "WARNING: possible circular locking dependency detected" with references to btrfs_read_locked_inode, btrfs_init_file_extent_tree, or fs_reclaim
• System hangs or unresponsive behavior when performing btrfs filesystem operations under memory pressure
• Lockdep warnings mentioning the chain "&delayed_node->mutex --> btrfs-tree-00 --> fs_reclaim"

Detection Strategies

• Monitor kernel logs for lockdep warnings related to btrfs filesystem operations using dmesg | grep -i "circular locking" or similar log analysis
• Enable CONFIG_PROVE_LOCKING and CONFIG_LOCKDEP kernel options to detect potential deadlocks before they occur
• Use kernel tracing with ftrace to monitor lock acquisition patterns in btrfs code paths
• Monitor for hung task warnings in dmesg that may indicate deadlock conditions

Monitoring Recommendations

• Implement automated log monitoring for kernel lockdep warnings containing "btrfs" or "fs_reclaim" in the message
• Set up alerts for system load anomalies that could indicate deadlock conditions on btrfs-mounted systems
• Review kernel crash dumps for evidence of deadlock states involving btrfs mutexes
• Monitor btrfs filesystems for unexpected latency spikes during high memory utilization periods

How to Mitigate CVE-2026-23018

Immediate Actions Required

• Apply the kernel patches from the stable git tree to resolve the circular lock dependency
• Consider temporarily reducing memory pressure on systems with btrfs filesystems until patches are applied
• Monitor affected systems for lockdep warnings and system instability
• Evaluate using alternative filesystems for critical workloads until the patch is applied

Patch Information

The Linux kernel developers have resolved this vulnerability by releasing the path before initializing the extent tree in btrfs_read_locked_inode(). The fix ensures that no locks are held across the GFP_KERNEL allocation, breaking the circular dependency chain.

Patches are available through the kernel stable git tree:

• Kernel Git Commit Log - Commit 8731f2c50b0b1d2b58ed5b9671ef2c4bdc2f8347
• Kernel Git Commit Reference - Commit 92a5590851144f034adc51fee55e6878ccac716e

Workarounds

• Reduce memory pressure on systems running btrfs by ensuring adequate available memory
• Limit concurrent file operations on btrfs filesystems during memory-constrained periods
• Consider mounting btrfs filesystems with noatime to reduce inode access overhead
• If possible, migrate critical workloads to other filesystem types until the kernel is patched

# Check current kernel version
uname -r

# Check if lockdep is enabled (for detection)
cat /sys/kernel/debug/lockdep_stats 2>/dev/null || echo "Lockdep not enabled or accessible"

# Monitor for lockdep warnings in real-time
dmesg -w | grep -i "circular locking"