CVE-2026-89856 in Linux
Summary
by MITRE • 09/16/2026
In the Linux kernel, the following vulnerability has been resolved:
scsi: qla2xxx: Clamp MSI-X derived queue counts to avoid truncation
ha->msix_count is u16, but ha->max_req_queues, ha->max_rsp_queues and ha->max_qpairs are u8. Deriving the queue count as "ha->max_req_queues = ha->msix_count - 1" therefore truncates: a board (or a misconfigured/malicious hot-plugged device) advertising 257 MSI-X vectors yields msix_count - 1 == 256, which truncates to 0. An MSI-X count of 1 zeroes it as well, and in target mode the subsequent "ha->max_req_queues--" then underflows 0 to 255.
When the count is 0, qla2x00_alloc_queues() calls kzalloc_objs(struct req_que *, 0), which returns ZERO_SIZE_PTR. That is not NULL, so the allocation check passes and the following "ha->req_q_map[0] = req" dereferences ZERO_SIZE_PTR, corrupting memory
or crashing the kernel.
Add qla_calc_queue_count() to clamp the derived value into [1, QLA_MAX_QUEUES - 1] so it always fits in u8 and is never zero, and
use it at all three derivation sites (qla25xx_iospace_config(), qla83xx_iospace_config() and qla24xx_enable_msix()). Also guard the target-mode decrement so it cannot reintroduce a zero (which would in turn underflow max_qpairs).
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/16/2026
The Linux kernel driver for QLogic Fibre Channel adapters, specifically the qla2xxx module, contained a critical integer truncation vulnerability stemming from incompatible data type sizes during MSI-X interrupt vector processing. The hardware abstraction structure utilized an unsigned 16-bit integer to store the total count of available MSI-X vectors, while the internal configuration structures for request queues, response queues, and queue pairs relied on unsigned 8-bit integers. This mismatch created a scenario where high values from the hardware could not be safely represented in the smaller data types used by the driver logic. When a system encountered a device advertising more than one hundred twenty-seven MSI-X vectors, or specifically when the count reached two hundred fifty-six due to truncation of larger counts like two hundred fifty-seven, the derived queue counts would incorrectly resolve to zero. This fundamental arithmetic error bypassed standard validation checks because the resulting value was technically valid for an unsigned 8-bit integer but logically invalid for memory allocation purposes.
The operational impact of this flaw is severe, leading directly to kernel instability and potential denial of service conditions. When the calculated queue count resulted in a value of zero, the driver invoked kzalloc_objs with a size parameter of zero. In Linux kernel memory management, allocating zero bytes does not return NULL but instead returns ZERO_SIZE_PTR, a special pointer indicating that no actual memory was allocated. The code subsequently proceeded to dereference this invalid pointer by assigning it to an array element within the request queue map. This action constitutes a critical out-of-bounds write or null-like pointer dereference depending on how the kernel handles ZERO_SIZE_PTR in subsequent operations, resulting in immediate memory corruption and system crash. Furthermore, in target mode configurations, a secondary flaw allowed for integer underflow where decrementing an already zeroed counter would wrap around to two hundred fifty-five, further destabilizing internal state variables like max_qpairs and exacerbating the risk of exploitation through malformed or maliciously configured hardware hot-plug events.
From a vulnerability classification perspective, this issue aligns with CWE-190 Integer Overflow or Wraparound, as the arithmetic operations failed to account for boundary conditions inherent in mixed-size integer types. The specific mechanism of deriving queue counts without proper bounds checking also reflects aspects of CWE-682 Incorrect Calculation, where the logic fails to produce a correct result due to improper handling of input values. In terms of attack vectors, this vulnerability could be leveraged by an attacker with physical access to insert or configure hardware that advertises excessive MSI-X capabilities, triggering the truncation and subsequent kernel crash during driver initialization. This maps to MITRE ATT&CK techniques involving device manipulation or supply chain compromise if malicious firmware is involved in advertising false interrupt counts. The lack of input validation on hardware-reported values represents a common weakness in low-level system drivers that assume hardware behavior conforms strictly to expected norms without defensive programming practices.
To mitigate this vulnerability, the driver implementation was updated to introduce a dedicated calculation function that clamps derived queue counts into a safe range bounded by one and the maximum supported queues minus one. This ensures that all internal variables remain within valid unsigned 8-bit limits and never reach zero, thereby preventing the allocation of ZERO_SIZE_PTR and subsequent memory corruption. The fix applies this validation logic consistently across multiple initialization paths including qla25xx_iospace_config, qla83xx_iospace_config, and qla24xx_enable_msix to ensure comprehensive coverage. Additionally, safeguards were added in target mode operations to prevent underflow when decrementing queue counters, ensuring that internal state variables like max_qpairs cannot wrap around to invalid high values. These changes enforce strict input validation on hardware-derived data, adhering to secure coding standards for kernel modules and preventing exploitation through malformed or maliciously configured peripheral devices.