CVE-2026-89857

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

• qla2xxxprocesspurls_pkt(), 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, qla2xxxprocesspurls_iocb(), runs inside

qla24xxprocessresponse_queue() 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 hardware_lock 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.