CVE-2026-23110
Modified Modified - Updated After Analysis
Race Condition in Linux Kernel SCSI Error Handler Causes I/O Hang

Publication date: 2026-02-04

Last updated on: 2026-05-04

Assigner: kernel.org

Description
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.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2026-02-04
Last Modified
2026-05-04
Generated
2026-05-27
AI Q&A
2026-02-04
EPSS Evaluated
2026-05-25
NVD
CVE-2026-23110
Affected Vendors & Products
Showing 11 associated CPEs
Vendor Product Version / Range
linux linux_kernel 6.19
linux linux_kernel 6.19
linux linux_kernel 6.19
linux linux_kernel 6.19
linux linux_kernel 6.19
linux linux_kernel From 6.2 (inc) to 6.6.122 (exc)
linux linux_kernel From 6.7 (inc) to 6.12.68 (exc)
linux linux_kernel From 6.13 (inc) to 6.18.8 (exc)
linux linux_kernel 6.19
linux linux_kernel From 5.11 (inc) to 6.1.162 (exc)
linux linux_kernel From 5.5 (inc) to 5.10.249 (exc)
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-362 The product contains a concurrent code sequence that requires temporary, exclusive access to a shared resource, but a timing window exists in which the shared resource can be modified by another code sequence operating concurrently.
Attack-Flow Graph
AI Powered Q&A
What immediate steps should I take to mitigate this vulnerability?

I don't know


Can you explain this vulnerability to me?

This vulnerability exists in the Linux kernel's SCSI core, where there is a race condition involving the error handler waking process. The issue arises from fragile ordering between marking SCSI commands as completed or failed, which can cause the error handler to not wake up properly when commands finish or time out.

Specifically, there are two main problems: first, a memory ordering issue in the function scsi_dec_host_busy() where writes clearing command states may be reordered with reads counting busy hosts, causing CPUs to have inconsistent views of the host's busy state. Second, an ordering issue in scsi_eh_inc_host_failed() where busy commands are counted before incrementing the host_failed count, leading to a race condition where neither function wakes the error handler.

These race conditions can cause the SCSI layer to fail to wake the error handler, leaving I/O operations stuck because the error state cannot progress.


How can this vulnerability impact me? :

This vulnerability can cause SCSI input/output operations to become stuck because the error handler responsible for managing failed or completed commands may not be properly woken up due to race conditions.

As a result, the system may experience delays or hangs in storage-related operations, potentially impacting system stability and performance where SCSI devices are involved.


How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:

I don't know


How can this vulnerability be detected on my network or system? Can you suggest some commands?

I don't know


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart