CVE-2026-23110

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.