CVE-2026-89860: scsi: qla2xxx: Initialize NVMe abort_work once at submission
In the Linux kernel, the following vulnerability has been resolved:
scsi: qla2xxx: Initialize NVMe abortwork once at submission
qlanvmefcpabort() and qlanvmelsabort() ran INITWORK() on priv->abortwork immediately before schedulework(). INITWORK() reinitializes the workstruct, resetting its list head and clearing the pending bit. If an abort is issued more than once for the same command (for example, concurrent transport teardown and a timeout-driven abort), the second INITWORK() reinitializes a work item that is already queued, which can corrupt the workqueue list and lead to crashes or a looping worker.
Initialize priv->abortwork once at command submission, next to the existing per-command spinlockinit(&priv->cmdlock), and leave only schedulework() in the abort paths. schedulework() already does nothing when the work item is still pending, so a repeated abort no longer disturbs an in-flight work item. The command is not returned to the transport until the final krefput()/release callback runs after abortwork has completed, so the work item is idle before priv is reused and the single submission-time INITWORK() is safe.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Fixed in 6.6.157.1-1 - Upgrade
Upgrade
debian/linuxto a version that resolves this vulnerability.Fixed in 6.12.113-1Fixed in 7.2.12-1Fixed in 7.2.13-1 - Upgrade
Upgrade
debian/linux-6.12to a version that resolves this vulnerability.Fixed in 6.12.113-1~deb12u1 - Compensating control
In the Linux kernel scsi/qla2xxx NVMe command path, initialize priv->abort_work once at command submission next to spin_lock_init(&priv->cmd_lock); do not reinitialize it in qla_nvme_fcp_abort() or qla_nvme_ls_abort(), and leave only schedule_work() in the abort paths.
Event History
Frequently Asked Questions
Which systems are exposed to this issue?
Systems using the Linux kernel qla2xxx driver with NVMe commands are exposed when the same command can receive more than one abort request. The described examples are concurrent transport teardown and a timeout-driven abort.
What must happen for exploitation or failure to occur?
An abort must be issued repeatedly for the same command while its abort work is already queued. The second abort reinitializes the queued work item, potentially corrupting the workqueue list and causing crashes or a looping worker.
Does a repeated abort still need to be prevented after the fix?
No. With abort_work initialized at command submission, repeated abort paths only call schedule_work(); it does nothing if the work item is already pending, leaving the in-flight item intact.
What behavior may indicate that a system is affected?
The reported outcomes are workqueue list corruption, kernel crashes, or a worker that loops. These symptoms would be associated with repeated abort handling for the same NVMe command in qla2xxx.