CVE-2026-23292: Linux Kernel Race Condition Vulnerability

CVE-2026-23292 Overview

A recursive locking vulnerability has been identified in the Linux kernel's SCSI target subsystem within the __configfs_open_file() function. The flaw occurs in the flush_write_buffer operation where the &p->frag_sem semaphore is acquired before calling the target_core_item_dbroot_store() function. This store function subsequently calls filp_open(), which triggers a chain of filesystem operations that attempt to re-acquire the same semaphore, leading to recursive locking conditions.

The vulnerability manifests when target_core_item_dbroot_store() attempts to validate a new file path by opening it. If the path points back to the same configfs file currently being operated on (such as /sys/kernel/config/target/dbroot), the system attempts to acquire the frag_sem semaphore in a nested manner while it's already held, creating a potential deadlock scenario.

Critical Impact

This vulnerability can lead to kernel deadlocks and system instability when specific configfs operations are performed on the SCSI target subsystem, potentially causing denial of service conditions.

Affected Products

• Linux Kernel (SCSI target subsystem with configfs support)
• Systems using target_core_mod kernel module
• Linux distributions with affected kernel versions

Discovery Timeline

• 2026-03-25 - CVE CVE-2026-23292 published to NVD
• 2026-03-25 - Last updated in NVD database

Technical Details for CVE-2026-23292

Vulnerability Analysis

The vulnerability exists in the interaction between the configfs filesystem and the SCSI target core subsystem. When a write operation is performed on a configfs file, the flush_write_buffer() function acquires the frag_sem semaphore before invoking the configured store callback. For SCSI target configfs entries, this callback is target_core_item_dbroot_store().

The problematic behavior occurs because target_core_item_dbroot_store() uses filp_open() to validate file paths. When the provided path references the same configfs file being written to, the kernel's VFS layer initiates a new open operation that traverses through do_filp_open() → path_openat() → do_open() → vfs_open() → do_dentry_open() → __configfs_open_file() → down_read(), ultimately attempting to acquire the frag_sem semaphore that is already held.

This creates a classic deadlock scenario where a thread blocks waiting for a resource it already possesses, which can result in system hangs or kernel soft lockup warnings.

Root Cause

The root cause is the use of filp_open() for path validation within a context where the configfs semaphore is already held. The filp_open() function triggers full filesystem open semantics, including the configfs-specific __configfs_open_file() handler, which requires acquiring the same frag_sem semaphore. This violates the kernel's locking hierarchy and creates a recursive lock acquisition attempt.

The fix modifies target_core_item_dbroot_store() to use kern_path() instead of filp_open(). The kern_path() function performs path resolution and validation without triggering filesystem-specific open handlers, thereby avoiding the configfs semaphore acquisition that causes the recursive locking condition.

Attack Vector

The attack vector for this vulnerability involves local access to the system with permissions to write to SCSI target configfs entries. An attacker or privileged user could trigger this condition by writing a specially crafted path (specifically, the path to the same dbroot configfs file) to the /sys/kernel/config/target/dbroot entry.

The call trace demonstrating the locking sequence is as follows:

1. configfs_write_iter initiates write operation
2. flush_write_buffer acquires frag_sem semaphore
3. target_core_item_dbroot_store is called as the store handler
4. filp_open is called to validate the provided path
5. VFS operations lead back to __configfs_open_file
6. down_read attempts to re-acquire frag_sem, causing deadlock

Detection Methods for CVE-2026-23292

Indicators of Compromise

• Kernel soft lockup warnings referencing configfs_write_iter or target_core_item_dbroot_store in stack traces
• System hangs when performing SCSI target configuration operations
• Kernel log messages indicating "db_root: not a directory: /sys/kernel/config/target/dbroot"
• Increased CPU usage with processes stuck in uninterruptible sleep state during configfs operations

Detection Strategies

• Monitor kernel logs for soft lockup warnings involving the SCSI target subsystem
• Implement audit rules for write operations to /sys/kernel/config/target/dbroot
• Deploy kernel tracing probes on target_core_item_dbroot_store and __configfs_open_file functions
• Use kernel livepatching detection tools to identify systems running vulnerable kernel versions

Monitoring Recommendations

• Configure system monitoring to alert on kernel soft lockup events
• Implement watchdog timers to detect and recover from potential deadlock conditions
• Monitor system responsiveness during SCSI target configuration changes
• Review kernel module loading logs for target_core_mod usage on production systems

How to Mitigate CVE-2026-23292

Immediate Actions Required

• Apply the kernel patches from the official Linux kernel git repository
• Restrict access to configfs SCSI target entries to only authorized administrators
• Avoid automated or scripted operations that write self-referential paths to dbroot
• Consider temporarily unloading the target_core_mod module if SCSI target functionality is not required

Patch Information

The Linux kernel developers have released patches to address this vulnerability. The fix replaces the use of filp_open() with kern_path() in target_core_item_dbroot_store() to avoid triggering filesystem-specific open handlers that cause the recursive locking condition.

Patch commits are available in the stable kernel git repository:

• Kernel Git Commit Update 1
• Kernel Git Commit Update 2
• Kernel Git Commit Update 3
• Kernel Git Commit Update 4
• Kernel Git Commit Update 5
• Kernel Git Commit Update 6

Workarounds

• Restrict write access to /sys/kernel/config/target/dbroot using filesystem permissions
• Implement input validation scripts to prevent writing self-referential paths
• Use SELinux or AppArmor policies to limit access to SCSI target configfs entries
• Monitor and audit all operations on the SCSI target configuration interface

# Restrict access to SCSI target configfs (temporary workaround)
chmod 600 /sys/kernel/config/target/dbroot
chown root:root /sys/kernel/config/target/dbroot

# Verify current kernel version for patch status
uname -r

# Check if target_core_mod is loaded
lsmod | grep target_core