Loop with Unreachable Exit Condition ('Infinite Loop') Affecting kernel-64k-core package, versions *
Threat Intelligence
The probability is the direct output of the EPSS model, and conveys an overall sense of the threat of exploitation in the wild. The percentile measures the EPSS probability relative to all known EPSS scores. Note: This data is updated daily, relying on the latest available EPSS model version. Check out the EPSS documentation for more details.
Do your applications use this vulnerable package?
In a few clicks we can analyze your entire application and see what components are vulnerable in your application, and suggest you quick fixes.
Test your applications- Snyk IDSNYK-CENTOS10-KERNEL64KCORE-20222307
- published29 Sept 2026
- disclosed25 Sept 2026
Introduced: 25 Sep 2026
NewCVE-2026-97530 (opens in a new tab)How to fix?
There is no fixed version for Centos:10 kernel-64k-core.
NVD Description
Note: Versions mentioned in the description apply only to the upstream kernel-64k-core package and not the kernel-64k-core package as distributed by Centos.
See How to fix? for Centos:10 relevant fixed versions and status.
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.
References
- https://bugzilla.redhat.com/show_bug.cgi?id=2541082
- https://access.redhat.com/security/cve/CVE-2026-97530
- https://git.kernel.org/stable/c/6aa722fca9d2aa1f64094101587f8f4a2f83f6aa
- https://git.kernel.org/stable/c/6e6c2ba9022eb8f9b062c81bdc6fd24c7b4c4c16
- https://git.kernel.org/stable/c/d7e3fa7d06bf7fcaac186d3c4d635caac166d36c