CVE-2026-89856: scsi: qla2xxx: Clamp MSI-X derived queue counts to avoid truncation
In the Linux kernel, the following vulnerability has been resolved:
scsi: qla2xxx: Clamp MSI-X derived queue counts to avoid truncation
ha->msixcount is u16, but ha->maxreqqueues, ha->maxrspqueues and ha->maxqpairs are u8. Deriving the queue count as "ha->maxreqqueues = ha->msixcount - 1" therefore truncates: a board (or a misconfigured/malicious hot-plugged device) advertising 257 MSI-X vectors yields msixcount - 1 == 256, which truncates to 0. An MSI-X count of 1 zeroes it as well, and in target mode the subsequent "ha->maxreqqueues--" then underflows 0 to 255.
When the count is 0, qla2x00allocqueues() calls kzallocobjs(struct reqque , 0), which returns ZEROSIZEPTR. That is not NULL, so the allocation check passes and the following "ha->reqqmap[0] = req" dereferences ZEROSIZEPTR, corrupting memory or crashing the kernel.
Add qlacalcqueuecount() to clamp the derived value into [1, QLAMAXQUEUES - 1] so it always fits in u8 and is never zero, and use it at all three derivation sites (qla25xxiospaceconfig(), qla83xxiospaceconfig() and qla24xxenablemsix()). Also guard the target-mode decrement so it cannot reintroduce a zero (which would in turn underflow maxqpairs).
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
Apply the fix so MSI-X derived queue counts are clamped via qla_calc_queue_count() to the range [1, QLA_MAX_QUEUES - 1], ensuring the derived u8 values (ha->max_req_queues / ha->max_rsp_queues and ha->max_qpairs) are never 0; use this clamping at all three derivation sites (qla25xx_iospace_config(), qla83xx_iospace_config(), qla24xx_enable_msix()).
Linux kernel scsi qla2xxx Clamp MSI-X derived queue counts = qla_calc_queue_count() clamps derived queue count into [1, QLA_MAX_QUEUES - 1] and ensures the count is never zero