CVE-2026-23110 in Linux
Summary
by MITRE • 02/04/2026
In the Linux kernel, the following vulnerability has been resolved:
scsi: core: Wake up the error handler when final completions race against each other
The fragile ordering between marking commands completed or failed so that the error handler only wakes when the last running command completes or times out has race conditions. These race conditions can cause the SCSI layer to fail to wake the error handler, leaving I/O through the SCSI host stuck as the error state cannot advance.
First, there is an memory ordering issue within scsi_dec_host_busy(). The write which clears SCMD_STATE_INFLIGHT may be reordered with reads counting in scsi_host_busy(). While the local CPU will see its own write, reordering can allow other CPUs in scsi_dec_host_busy() or scsi_eh_inc_host_failed() to see a raised busy count, causing no CPU to see a host busy equal to the host_failed count.
This race condition can be prevented with a memory barrier on the error path to force the write to be visible before counting host busy commands.
Second, there is a general ordering issue with scsi_eh_inc_host_failed(). By counting busy commands before incrementing host_failed, it can race with a final command in scsi_dec_host_busy(), such that scsi_dec_host_busy() does not see host_failed incremented but scsi_eh_inc_host_failed() counts busy commands before SCMD_STATE_INFLIGHT is cleared by scsi_dec_host_busy(), resulting in neither waking the error handler task.
This needs the call to scsi_host_busy() to be moved after host_failed is incremented to close the race condition.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 05/03/2026
The vulnerability described in CVE-2026-23110 represents a critical race condition within the Linux kernel's SCSI subsystem that can lead to complete I/O deadlock conditions. This flaw exists in the scsi core layer where the error handling mechanism fails to properly coordinate between command completion and error state advancement. The vulnerability manifests when multiple commands race against each other during their final completion phases, creating a scenario where the error handler thread fails to wake up properly. This results in I/O operations becoming permanently stuck on SCSI hosts, as the system cannot advance from an error state to recover or retry failed operations. The issue specifically impacts the SCSI subsystem's ability to maintain proper state transitions and can cause significant system instability, particularly in environments with high I/O throughput or critical storage workloads where SCSI devices are heavily utilized.
The technical implementation of this vulnerability involves two primary memory ordering issues that stem from improper synchronization between different kernel subsystems. The first issue occurs within the scsi_dec_host_busy() function where memory reordering allows writes that clear the SCMD_STATE_INFLIGHT flag to be reordered with reads in scsi_host_busy(). This creates a scenario where different CPU cores can observe inconsistent states, leading to situations where no CPU sees the host busy count drop to match the host_failed count. The second race condition involves the ordering of operations in scsi_eh_inc_host_failed() where busy command counting occurs before incrementing the host_failed counter. This creates a timing window where scsi_dec_host_busy() may complete its operations without seeing the incremented host_failed value, preventing the error handler from being awakened. These race conditions are classified under CWE-362, which describes race conditions that can lead to security vulnerabilities and system instability.
The operational impact of this vulnerability can be severe, particularly in enterprise storage environments where SCSI devices are commonly used for high-performance storage arrays, database operations, and mission-critical applications. When the error handler fails to wake up due to these race conditions, I/O operations can become indefinitely blocked, potentially leading to complete system hangs or application timeouts. The vulnerability affects the core SCSI error handling mechanism, which means that any application or service relying on SCSI storage for data operations can be impacted. In production environments, this could manifest as storage subsystem failures, application crashes, or complete system unresponsiveness, depending on the specific workload and timing of the race conditions. The issue is particularly concerning because it operates at the kernel level and can affect the fundamental I/O operations that underpin system stability and data integrity.
Mitigation strategies for CVE-2026-23110 require immediate kernel updates to address the memory ordering issues and synchronization problems within the SCSI subsystem. System administrators should prioritize applying the relevant kernel patches that implement proper memory barriers and reordering fixes in the scsi_dec_host_busy() and scsi_eh_inc_host_failed() functions. The fix involves implementing memory barriers on the error path to ensure writes are visible before busy count operations and reordering the sequence of operations in scsi_eh_inc_host_failed() to increment host_failed before counting busy commands. Organizations should also implement monitoring solutions to detect stalled I/O operations and establish backup procedures for systems where SCSI storage is critical. From an ATT&CK framework perspective, this vulnerability relates to privilege escalation and system stability compromise, as it can be exploited to cause denial of service conditions and potentially allow attackers to disrupt critical storage operations. The vulnerability demonstrates the importance of proper synchronization primitives in kernel code and highlights the need for comprehensive testing of concurrent operations in storage subsystems.