CVE-2026-89842 in Linux
Summary
by MITRE • 09/16/2026
In the Linux kernel, the following vulnerability has been resolved:
scsi: qla2xxx: Skip NVMe LS reject IOCB when FW not started
qla_nvme_xmt_ls_rsp() bails out to the out: label when firmware is not started (!ha->flags.fw_started), but the out: path unconditionally calls qla_nvme_ls_reject_iocb(), which ends in qla2x00_start_iocbs() 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 fw_started is also clear.
Only emit the LS reject IOCB (and ring the doorbell) when fw_started is set; otherwise just clean up and return. The post-allocation failure cases (SRB alloc / qla2x00_start_sp() failure) run with firmware started and still send the reject. Apply the same guard to the reject emission in qla2xxx_process_purls_pkt().
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 09/16/2026
The vulnerability identified within the Linux kernel's SCSI subsystem, specifically affecting the QLogic qla2xxx driver, represents a critical race condition involving hardware state management during firmware initialization or reset sequences. The core issue resides in the function qla_nvme_xmt_ls_rsp(), which is responsible for transmitting NVMe Link Service responses. Under normal operational conditions, this routine functions correctly; however, it fails to adequately verify the status of the host adapter's firmware before attempting to interact with hardware registers. Specifically, when the firmware is not started, indicated by a false value in ha->flags.fw_started, the code path branches to an error handling label labeled out. This branch was designed to clean up resources and return control to the caller, but it contains a critical flaw where it unconditionally invokes qla2x00_start_iocbs() via qla_nvme_ls_reject_iocb().
This unconditional invocation leads to a doorbell write operation targeting the request queue in-pointer register. In QLogic hardware architecture, writing to this specific memory-mapped I/O address serves as an interrupt mechanism that signals the firmware to process new commands queued in the host's memory buffers. When the firmware is not started because it is currently resetting or recovering from an Extended Error Handling event, such a doorbell write is fundamentally unsafe. The firmware cannot consume these IOCBs during this window, leading to undefined behavior within the driver-firmware interface. Furthermore, performing Memory-Mapped I/O operations while the device is in a reset state can cause system instability, potential kernel panics, or data corruption due to hardware not being ready to accept such commands.
The operational impact of this vulnerability extends beyond simple functional errors. By sending an IOCB that cannot be processed and triggering a doorbell interrupt during a critical firmware transition period, the driver introduces significant latency in recovery processes. In severe cases, particularly on systems relying on NVMe over Fabrics or high-performance storage arrays utilizing QLogic adapters, this can result in I/O timeouts, device unavailability, or complete system hangs. The issue is exacerbated by the fact that post-allocation failure paths, such as those triggered when SRB allocation fails or qla2x00_start_sp() encounters an error while firmware is active, still proceed to send reject packets correctly. This inconsistency highlights a lack of uniform state checking across different code paths within the driver's NVMe handling logic.
To mitigate this vulnerability, the fix involves introducing explicit guards around the emission of Link Service reject IOCBs and subsequent doorbell writes. The corrected implementation ensures that these hardware interactions only occur when ha->flags.fw_started is true, confirming that the firmware is in a stable, operational state capable of processing commands. If the firmware is not started, the driver now performs necessary cleanup routines and returns immediately without attempting to queue IOCBs or trigger interrupts. This logic has also been applied consistently to qla2xxx_process_purls_pkt() to ensure uniform behavior across all NVMe Link Service handling paths in the driver.
From a classification perspective, this vulnerability aligns with CWE-367, which describes Time-of-check Time-of-use (TOCTOU) race conditions, as the code checks for firmware status but fails to maintain that assumption during subsequent hardware interactions. Additionally, it relates to CWE-459 regarding Incomplete Cleanup, where resources are not properly managed due to premature exit paths ignoring state constraints. The attack vector is primarily local and requires physical or administrative access to trigger specific failure conditions like SRB allocation failures during firmware reset windows. Mitigation strategies for system administrators include applying the latest kernel updates that contain this patch. For environments unable to update immediately, monitoring logs for qla2xxx driver errors related to NVMe Link Services and ensuring stable power delivery to prevent unexpected resets can reduce exposure risk until a permanent fix is deployed.