CVE-2026-89842: scsi: qla2xxx: Skip NVMe LS reject IOCB when FW not started
In the Linux kernel, the following vulnerability has been resolved:
scsi: qla2xxx: Skip NVMe LS reject IOCB when FW not started
qlanvmexmtlsrsp() bails out to the out: label when firmware is not started (!ha->flags.fwstarted), but the out: path unconditionally calls qlanvmelsrejectiocb(), which ends in qla2x00startiocbs() and an unconditional doorbell write to the request queue in-pointer register. This rings the firmware doorbell and queues an IOCB that stopped or resetting firmware cannot consume, and touches MMIO during the reset/EEH window where fwstarted is also clear.
Only emit the LS reject IOCB (and ring the doorbell) when fwstarted is set; otherwise just clean up and return. The post-allocation failure cases (SRB alloc / qla2x00startsp() failure) run with firmware started and still send the reject. Apply the same guard to the reject emission in qla2xxxprocesspurlspkt().
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.1.176-1Fixed in 6.1.190-1Fixed in 6.12.115-2Fixed in 7.2.12-1Fixed in 7.2.15-1 - Upgrade
Upgrade
debian/linux-6.12to a version that resolves this vulnerability.Fixed in 6.12.113-1~deb12u1 - Upgrade
Upgrade
ubuntu/linux-hwe-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-42.42~24.04.1 - Upgrade
Upgrade
ubuntu/linux-riscv-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-42.42.1~24.04.1 - Upgrade
Upgrade
ubuntu/linuxto a version that resolves this vulnerability.Fixed in 7.0.0-42.42 - Upgrade
Upgrade
ubuntu/linux-awsto a version that resolves this vulnerability.Fixed in 7.0.0-1016.17 - Upgrade
Upgrade
ubuntu/linux-gcpto a version that resolves this vulnerability.Fixed in 7.0.0-1016.18 - Upgrade
Upgrade
ubuntu/linux-ibmto a version that resolves this vulnerability.Fixed in 7.0.0-1017.17 - Upgrade
Upgrade
ubuntu/linux-oem-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1017.17 - Upgrade
Upgrade
ubuntu/linux-oracleto a version that resolves this vulnerability.Fixed in 7.0.0-1015.16 - Upgrade
Upgrade
ubuntu/linux-riscvto a version that resolves this vulnerability.Fixed in 7.0.0-42.42.1 - Compensating control
Guard NVMe LS reject emission in qla_nvme_xmt_ls_rsp() and qla2xxx_process_purls_pkt() so qla_nvme_ls_reject_iocb() is called, and the firmware doorbell is rung, only when ha->flags.fw_started is set; otherwise clean up and return.
Event History
Frequently Asked Questions
When can this issue be triggered?
It occurs when the qla2xxx driver handles an NVMe LS response or PURLs packet while adapter firmware is stopped, resetting, or in an EEH window, as indicated by fw_started being clear. In that state, the affected paths can still issue a reject IOCB and ring the firmware doorbell.
What is the practical impact during a firmware reset or EEH event?
The driver can queue an IOCB for firmware that cannot consume it and perform an MMIO doorbell write during the reset or EEH window. The fix avoids both actions when firmware has not started, while preserving reject handling for allocation and start failures that occur with firmware running.
How can I determine whether the fix is present?
Check whether the qla2xxx driver guards reject IOCB emission in both qla_nvme_xmt_ls_rsp() and qla2xxx_process_purls_pkt() so that qla_nvme_ls_reject_iocb() is called only when fw_started is set. The listed kernel stable references contain the corresponding changes.