CVE-2026-89857: scsi: qla2xxx: Hold qpair lock when sending NVMe LS reject
In the Linux kernel, the following vulnerability has been resolved:
scsi: qla2xxx: Hold qpair lock when sending NVMe LS reject
qlanvmelsrejectiocb() allocates from and advances the request ring through qla2x00allociocbs() (which assumes the hardwarelock is held) and qla2x00startiocbs() (which advances the ring and rings the request-in doorbell), but takes no lock itself. Two of its callers invoke it without the producer lock held:
- qlanvmexmtlsrsp(), the NVMe-FC .xmtlsrsp transport callback, on its error path, and
- qla2xxxprocesspurlspkt(), run from the purex work/DPC context.
Both use ha->baseqpair, whose qplockptr is hardwarelock, so they can run concurrently with normal I/O submission on the base ring and corrupt the ring producer state, leading to duplicated or dropped commands. The third caller, qla2xxxprocesspurlsiocb(), runs inside qla24xxprocessresponsequeue() with the qpair lock already held and is safe; that is also why the lock cannot be taken inside the helper itself (it would recursively re-acquire hardwarelock on the response path).
Take qplockptr around the two unlocked callers and document the helper as caller-locked. Both run in process context, so spinlockirqsave() is used and nothing in the locked region sleeps.
Affected Software
Event History
Frequently Asked Questions
Which systems are exposed to this issue?
Systems using the Linux qla2xxx driver with NVMe-FC link-service response handling or Purex processing can reach the unlocked paths. The race involves the adapter's base queue pair running concurrently with normal I/O submission.
What is required for the race to occur?
An unlocked NVMe LS reject submission must run concurrently with normal I/O on the base request ring. The affected paths are the error path of the NVMe-FC xmt_ls_rsp callback and the Purex work/DPC processing path.
What is the operational impact?
Concurrent updates to the request-ring producer state can corrupt that state, resulting in duplicated or dropped commands. The description does not identify an impact beyond command handling corruption.
Is every caller of the affected helper unsafe?
No. The response-queue path through qla2xxx_process_purls_iocb() already holds the queue-pair lock and is described as safe. The two callers that lacked this lock are the ones addressed by the fix.
What should be done to remediate the issue?
Apply a Linux kernel update containing the referenced fixes. The remediation adds queue-pair locking around the two previously unlocked callers before they allocate and submit request-ring IOCBs.