CVE-2026-23110

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: core: Wake up the error handler when final completions race against each other<br /> <br /> The fragile ordering between marking commands completed or failed so<br /> that the error handler only wakes when the last running command<br /> completes or times out has race conditions. These race conditions can<br /> cause the SCSI layer to fail to wake the error handler, leaving I/O<br /> through the SCSI host stuck as the error state cannot advance.<br /> <br /> First, there is an memory ordering issue within scsi_dec_host_busy().<br /> The write which clears SCMD_STATE_INFLIGHT may be reordered with reads<br /> counting in scsi_host_busy(). While the local CPU will see its own<br /> write, reordering can allow other CPUs in scsi_dec_host_busy() or<br /> scsi_eh_inc_host_failed() to see a raised busy count, causing no CPU to<br /> see a host busy equal to the host_failed count.<br /> <br /> This race condition can be prevented with a memory barrier on the error<br /> path to force the write to be visible before counting host busy<br /> commands.<br /> <br /> Second, there is a general ordering issue with scsi_eh_inc_host_failed(). By<br /> counting busy commands before incrementing host_failed, it can race with a<br /> final command in scsi_dec_host_busy(), such that scsi_dec_host_busy() does<br /> not see host_failed incremented but scsi_eh_inc_host_failed() counts busy<br /> commands before SCMD_STATE_INFLIGHT is cleared by scsi_dec_host_busy(),<br /> resulting in neither waking the error handler task.<br /> <br /> This needs the call to scsi_host_busy() to be moved after host_failed is<br /> incremented to close the race condition.