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

bash

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