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 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, e
- Products
- Kernel
- Affected versions
- Not specified
- Fixed versions
- 5.15.224, 6.1.191, 6.12.112, 6.18.53, 6.6.160, 7.2.7
- CVEs
- CVE-2026-97530
- Confirmed fixed CVEs
- Not specified
- Updated in this feed
- 3 Nov 2026, 17:22 UTC · Revision 1
Source evidence
scsi: qla2xxx: Fix soft lockup polling continuation IOCB signature
core-osv · Original sourcePublished 25 Sept 2026, 10:21 UTC
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, e
osv:CVE-2026-97530
Kernel
Fixed versions: 5.15.224, 6.1.191, 6.6.160, 6.12.112, 6.18.53, 7.2.7
Complete source record
{
"id": "739b453b9555043e0941ee329a9dee9450569900c3b943889cb88e537215ebd0",
"url": "https://osv.dev/vulnerability/CVE-2026-97530",
"method": "structured",
"payload": {
"kind": "advisory",
"title": "scsi: qla2xxx: Fix soft lockup polling continuation IOCB signature",
"summary": "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, e",
"evidence": "osv:CVE-2026-97530",
"products": [
{
"name": {
"value": "Kernel",
"evidence": "/affected/1/package/name"
},
"prerequisites": [],
"fixed_versions": [
{
"value": "5.15.224",
"evidence": "/affected/1/ranges"
},
{
"value": "6.1.191",
"evidence": "/affected/1/ranges"
},
{
"value": "6.6.160",
"evidence": "/affected/1/ranges"
},
{
"value": "6.12.112",
"evidence": "/affected/1/ranges"
},
{
"value": "6.18.53",
"evidence": "/affected/1/ranges"
},
{
"value": "7.2.7",
"evidence": "/affected/1/ranges"
}
],
"affected_versions": []
}
],
"severity": "unknown",
"structured": {
"id": "CVE-2026-97530",
"aliases": [
"CVE-2026-97530"
],
"affected": [
{
"ranges": [
{
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"type": "GIT",
"events": [
{
"introduced": "9f2475fe7406b8ef5f97099c4980021344872d9f"
},
{
"fixed": "bded2de273c5b0e50e3e23de937260436cd67df2"
},
{
"fixed": "70df7f03499046da0d28a58ec8b237ed5dfbd0a7"
},
{
"fixed": "428e244dd4066abd40ca1ec525b7aab9a9db8296"
},
{
"fixed": "3e58eb888ebf265af937f636d05997c60d2f197c"
},
{
"fixed": "6e6c2ba9022eb8f9b062c81bdc6fd24c7b4c4c16"
},
{
"fixed": "6aa722fca9d2aa1f64094101587f8f4a2f83f6aa"
},
{
"fixed": "d7e3fa7d06bf7fcaac186d3c4d635caac166d36c"
}
]
}
],
"database_specific": {
"source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-97530.json"
}
},
{
"ranges": [
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "5.9.0"
},
{
"fixed": "5.15.224"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "5.16.0"
},
{
"fixed": "6.1.191"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "6.2.0"
},
{
"fixed": "6.6.160"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "6.7.0"
},
{
"fixed": "6.12.112"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "6.13.0"
},
{
"fixed": "6.18.53"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "6.19.0"
},
{
"fixed": "7.2.7"
}
]
}
],
"package": {
"name": "Kernel",
"ecosystem": "Linux"
},
"database_specific": {
"source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-97530.json"
}
}
],
"modified": "2026-11-01T02:30:29.856888610Z",
"provider": "osv",
"references": [
"https://git.kernel.org/stable/c/3e58eb888ebf265af937f636d05997c60d2f197c",
"https://git.kernel.org/stable/c/428e244dd4066abd40ca1ec525b7aab9a9db8296",
"https://git.kernel.org/stable/c/6aa722fca9d2aa1f64094101587f8f4a2f83f6aa",
"https://git.kernel.org/stable/c/6e6c2ba9022eb8f9b062c81bdc6fd24c7b4c4c16",
"https://git.kernel.org/stable/c/70df7f03499046da0d28a58ec8b237ed5dfbd0a7",
"https://git.kernel.org/stable/c/bded2de273c5b0e50e3e23de937260436cd67df2",
"https://git.kernel.org/stable/c/d7e3fa7d06bf7fcaac186d3c4d635caac166d36c",
"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/97xxx/CVE-2026-97530.json",
"https://nvd.nist.gov/vuln/detail/CVE-2026-97530",
"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git"
],
"provider_metadata": {
"cna_assigner": "Linux",
"osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/97xxx/CVE-2026-97530.json"
}
},
"related_cves": [
{
"value": "CVE-2026-97530",
"evidence": "/id"
}
],
"security_relevant": true,
"severity_evidence": null
},
"source_id": "core-osv",
"document_id": 497753,
"published_at": "2026-09-25T10:21:31.326+00:00"
}