DEBIAN-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   - 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.