CVE-2026-97530scsi: qla2xxx: Fix soft lockup polling continuation IOCB signature
Updated under an hour ago ()
Does this affect you?
It affects Linux. Add what you run to find out whether that includes you.
No exploitation reported and no EPSS estimate yet.
Do this next
Free account, 1 product
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.
- CVSS
- Not yet scored
- Weakness (CWE)
- Not given
- Known exploited
- Not in CISA's KEV catalog
- EPSS (exploitation in the next 30 days)
- Not loaded for this CVE
- Assigned by
- Linux
- NVD analysis
- Received
- Record last updated
- Oct 3, 2026
- First seen by InfoSec Signals
- Oct 9, 2026
Affected products
Linux Linux linux:linux (from the name) | 9f2475fe7406b8ef5f97099c4980021344872d9f builds before 3e58eb888ebf265af937f636d05997c60d2f197c; 9f2475fe7406b8ef5f97099c4980021344872d9f builds before 6e6c2ba9022eb8f9b062c81bdc6fd24c7b4c4c16; 9f2475fe7406b8ef5f97099c4980021344872d9f builds before 6aa722fca9d2aa1f64094101587f8f4a2f83f6aa; from 9f2475fe7406b8ef5f97099c4980021344872d9f before d7e3fa7d06bf7fcaac186d3c4d635caac166d36c | CNA record |
References
- https://git.kernel.org/stable/c/3e58eb888ebf265af937f636d05997c60d2f197c
- https://git.kernel.org/stable/c/6e6c2ba9022eb8f9b062c81bdc6fd24c7b4c4c16
- https://git.kernel.org/stable/c/6aa722fca9d2aa1f64094101587f8f4a2f83f6aa
- https://git.kernel.org/stable/c/d7e3fa7d06bf7fcaac186d3c4d635caac166d36c
The CVE record on cve.org NVD's entry
The CVE record is authoritative. Products marked “from the name” were identified from the CNA's free-text names, not a CPE, and are matched less certainly. This product uses the NVD API but is not endorsed or certified by the NVD.