CVE-2026-23292 in Linux
Summary
by MITRE • 03/25/2026
In the Linux kernel, the following vulnerability has been resolved:
scsi: target: Fix recursive locking in __configfs_open_file()
In flush_write_buffer, &p->frag_sem is acquired and then the loaded store function is called, which, here, is target_core_item_dbroot_store(). This function called filp_open(), following which these functions were called (in reverse order), according to the call trace:
down_read __configfs_open_file do_dentry_open vfs_open do_open path_openat do_filp_open file_open_name filp_open target_core_item_dbroot_store flush_write_buffer configfs_write_iter
target_core_item_dbroot_store() tries to validate the new file path by trying to open the file path provided to it; however, in this case, the bug report shows:
db_root: not a directory: /sys/kernel/config/target/dbroot
indicating that the same configfs file was tried to be opened, on which it is currently working on. Thus, it is trying to acquire frag_sem semaphore of the same file of which it already holds the semaphore obtained in flush_write_buffer(), leading to acquiring the semaphore in a nested manner and a possibility of recursive locking.
Fix this by modifying target_core_item_dbroot_store() to use kern_path() instead of filp_open() to avoid opening the file using filesystem-specific function __configfs_open_file(), and further modifying it to make this fix compatible.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 07/02/2026
The vulnerability identified as CVE-2026-23292 represents a critical recursive locking issue within the Linux kernel's SCSI target subsystem, specifically affecting the configfs implementation. This flaw exists in the __configfs_open_file() function where the kernel attempts to validate file paths through nested filesystem operations that create dangerous lock acquisition patterns. The vulnerability manifests when the target_core_item_dbroot_store() function is invoked during flush_write_buffer() processing, creating a scenario where the same semaphore protecting a configfs file is attempted to be acquired twice in nested fashion, leading to potential deadlocks and system instability.
The technical implementation flaw stems from the improper use of filp_open() within the target_core_item_dbroot_store() function, which triggers a cascade of filesystem operations that ultimately calls __configfs_open_file() again while holding the frag_sem semaphore. This creates a classic recursive locking condition where the same synchronization primitive is acquired twice by the same execution context, violating fundamental lock ordering principles and potentially causing kernel panics or system hangs. The specific error message "db_root: not a directory: /sys/kernel/config/target/dbroot" indicates that the validation process attempted to open the very same configfs entry it was currently processing, creating an infinite loop of semaphore acquisition.
From an operational security perspective, this vulnerability presents a significant risk to systems utilizing SCSI target functionality with configfs configuration, particularly in storage environments where kernel stability is paramount. Attackers could potentially exploit this recursive locking condition to cause system crashes or denial of service conditions, though the attack surface is limited to systems actively using the affected kernel subsystem. The vulnerability aligns with CWE-367, which addresses Time-of-Check to Time-of-Use (TOCTOU) race conditions, and maps to ATT&CK technique T1499.004 for endpoint denial of service through resource exhaustion or lock acquisition manipulation. The flaw demonstrates poor lock management practices and highlights the importance of avoiding nested acquisition of the same synchronization primitives in kernel space.
The mitigation strategy involves modifying the target_core_item_dbroot_store() function to replace filp_open() with kern_path() for path validation operations, eliminating the need for filesystem-specific opening operations that trigger the recursive lock acquisition. This approach ensures that path validation occurs without entering the problematic __configfs_open_file() code path, while maintaining compatibility with existing functionality. The fix requires careful attention to maintain the semantic correctness of path validation while preventing the recursive lock scenario, and should be implemented with thorough testing to ensure no regression in normal operation. The solution addresses the root cause by breaking the circular dependency in lock acquisition patterns and aligns with kernel security best practices for preventing deadlocks in complex subsystems.