CVE-2026-97530

Status: UPDATED  |  Advisory ID: CVE-2026-97530

Key Details

Affected Products, Subsystems & Sectors

What to Know

In the Linux kernel, the following vulnerability has been resolved:

scsi: qla2xxx: Fix soft lockup polling continuation IOCB signature

qla27xx_copy_multiple_pkt() and qla27xx_copy_fpin_pkt() poll

rsp_q->ring_ptr->signature for RESPONSE_PROCESSED (0xDEADDEAD) to decide

whether the next continuation IOCB has arrived, spinning on cpu_relax()

without advancing the ring or decrementing the entry count while it has

not. response_t::signature lives at byte offset 60, but a continuation

IOCB (sts_cont_entry_t / struct sts_cont_entry_ext) 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 qla27xx_copy_multiple_pkt()

(PT_LS4_UNSOL and the NVMe purls path) already gate on

qla_chk_cont_iocb_avail(), which guarantees all entry_count IOCBs are

present before copying begins. The sibling helper

__qla_copy_purex_to_buffer() already drops the signature poll and relies

on the entry_type == STATUS_CONT_TYPE guard instead.

Remove the signature busy-wait from both helpers, keeping the entry_type

guard, and gate the FPIN path with qla_chk_cont_iocb_avail() so it defers

and re-processes on the next interrupt once all continuation IOCBs have

arrived, mirroring the ELS_AUTH_ELS and PT_LS4_UNSOL arms. With this the

signature field is never read on a continuation IOCB, eliminating the

payload-aliasing lockup. (NVD)

What to Do

Monitor Linux's web page for any future patch releases.

References