CVE-2026-97530: scsi: qla2xxx: Fix soft lockup polling continuation IOCB signature
In the Linux kernel, the following vulnerability has been resolved:
scsi: qla2xxx: Fix soft lockup polling continuation IOCB signature
qla27xxcopymultiplepkt() and qla27xxcopyfpinpkt() poll rspq->ringptr->signature for RESPONSEPROCESSED (0xDEADDEAD) to decide whether the next continuation IOCB has arrived, spinning on cpurelax() without advancing the ring or decrementing the entry count while it has not. responset::signature lives at byte offset 60, but a continuation IOCB (stscontentryt / struct stscontentryext) carries raw FC frame payload at that offset (data[56..59]). A received frame whose payload bytes happen to equal 0xDEADDEAD is therefore misread as "not yet arrived", and the loop spins forever in interrupt/DPC context, causing a CPU soft lockup.
The poll is also unnecessary: callers of qla27xxcopymultiplepkt() (PTLS4UNSOL and the NVMe purls path) already gate on qlachkcontiocbavail(), which guarantees all entrycount IOCBs are present before copying begins. The sibling helper qlacopypurextobuffer() already drops the signature poll and relies on the entrytype == STATUSCONTTYPE guard instead.
Remove the signature busy-wait from both helpers, keeping the entrytype guard, and gate the FPIN path with qlachkcontiocbavail() so it defers and re-processes on the next interrupt once all continuation IOCBs have arrived, mirroring the ELSAUTHELS and PTLS4UNSOL arms. With this the signature field is never read on a continuation IOCB, eliminating the payload-aliasing lockup.
Affected Software
Event History
Frequently Asked Questions
Which systems are exposed to this issue?
Systems using the Linux kernel qla2xxx SCSI driver are exposed when they process the affected continuation IOCB paths, including PT_LS4 unsolicited traffic and the NVMe purls path. The issue occurs in interrupt/DPC context.
What must an attacker or triggering input do to cause the lockup?
A received Fibre Channel frame must place the value 0xDEADDEAD in payload bytes corresponding to the continuation IOCB signature offset. The driver can then misinterpret the continuation IOCB as not yet available and spin indefinitely on cpu_relax().
What is the operational impact?
The affected CPU can enter a soft lockup while the driver waits for a continuation IOCB that has already arrived. This is a denial-of-service condition rather than evidence of data exposure or modification.
How can administrators identify the affected behavior?
Look for Linux kernel soft-lockup reports involving qla27xx_copy_multiple_pkt() or qla27xx_copy_fpin_pkt(), particularly while handling Fibre Channel traffic. The faulty path repeatedly polls the response ring IOCB signature instead of advancing through available continuation entries.