[<prev] [next>] [day] [month] [year] [list]
Message-ID: <2026020431-CVE-2026-23110-56b1@gregkh>
Date: Wed, 4 Feb 2026 17:15:09 +0100
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: linux-cve-announce@...r.kernel.org
Cc: Greg Kroah-Hartman <gregkh@...nel.org>
Subject: CVE-2026-23110: scsi: core: Wake up the error handler when final completions race against each other
From: Greg Kroah-Hartman <gregkh@...nel.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.
The Linux kernel CVE team has assigned CVE-2026-23110 to this issue.
Affected and fixed versions
===========================
Issue introduced in 5.5 with commit 6eb045e092efefafc6687409a6fa6d1dabf0fb69 and fixed in 6.6.122 with commit 9fdc6f28d5e81350ab1d2cac8389062bd09e61e1
Issue introduced in 5.5 with commit 6eb045e092efefafc6687409a6fa6d1dabf0fb69 and fixed in 6.12.68 with commit 64ae21b9c4f0c7e60cf47a53fa7ab68852079ef0
Issue introduced in 5.5 with commit 6eb045e092efefafc6687409a6fa6d1dabf0fb69 and fixed in 6.18.8 with commit 219f009ebfd1ef3970888ee9eef4c8a06357f862
Issue introduced in 5.5 with commit 6eb045e092efefafc6687409a6fa6d1dabf0fb69 and fixed in 6.19-rc7 with commit fe2f8ad6f0999db3b318359a01ee0108c703a8c3
Please see https://www.kernel.org for a full list of currently supported
kernel versions by the kernel community.
Unaffected versions might change over time as fixes are backported to
older supported kernel versions. The official CVE entry at
https://cve.org/CVERecord/?id=CVE-2026-23110
will be updated if fixes are backported, please check that for the most
up to date information about this issue.
Affected files
==============
The file(s) affected by this issue are:
drivers/scsi/scsi_error.c
drivers/scsi/scsi_lib.c
Mitigation
==========
The Linux kernel CVE team recommends that you update to the latest
stable kernel version for this, and many other bugfixes. Individual
changes are never tested alone, but rather are part of a larger kernel
release. Cherry-picking individual commits is not recommended or
supported by the Linux kernel community at all. If however, updating to
the latest release is impossible, the individual changes to resolve this
issue can be found at these commits:
https://git.kernel.org/stable/c/9fdc6f28d5e81350ab1d2cac8389062bd09e61e1
https://git.kernel.org/stable/c/64ae21b9c4f0c7e60cf47a53fa7ab68852079ef0
https://git.kernel.org/stable/c/219f009ebfd1ef3970888ee9eef4c8a06357f862
https://git.kernel.org/stable/c/fe2f8ad6f0999db3b318359a01ee0108c703a8c3
Powered by blists - more mailing lists