CVE-2026-93242 in Linux
Summary
by MITRE • 09/24/2026
In the Linux kernel, the following vulnerability has been resolved:
scsi: qla2xxx: Fix response queue over-consumption in __qla_consume_iocb()
qla24xx_process_response_queue() advances ring_ptr past the head IOCB before dispatching, so by the time __qla_consume_iocb() runs, ring_ptr already points at the first continuation IOCB. The function however looped purex->entry_count times starting at ring_ptr. As entry_count includes the head, this consumed one entry too many: it stamped RESPONSE_PROCESSED on the next, unrelated IOCB and advanced the ring past it, silently dropping a legitimate firmware response. The head IOCB's signature was also never marked.
Mark the head processed and account for it, then consume only the entry_count - 1 continuation IOCBs, matching __qla_copy_purex_to_buffer().
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/24/2026
The Linux kernel driver qla2xxx manages Fibre Channel host bus adapters from QLogic, handling critical I/O operations between the operating system and storage hardware. A specific logic error within the response queue processing mechanism introduces a race condition that can lead to data corruption or loss of legitimate firmware responses. The vulnerability resides in the __qla_consume_iocb function, which is responsible for consuming Input/Output Control Blocks from the device's response ring after they have been processed by the hardware. This issue stems from an off-by-one error in how the driver iterates through and marks completed entries on the circular buffer used to communicate with the firmware.
The root cause of this vulnerability lies in the interaction between qla24xx_process_response_queue and __qla_consume_iocb. The former function advances a ring pointer past the head IOCB before dispatching it for processing. Consequently, when __qla_consume_iocb executes, its internal ring_ptr variable already points to what is technically the first continuation entry rather than the original head of the response chain. Despite this shift in position, the loop within __qla_consume_iocb iterates exactly purex->entry_count times starting from this new pointer location. Since entry_count includes both the head IOCB and all subsequent continuation entries, iterating that many times from a shifted start point results in consuming one additional entry beyond what was intended.
This off-by-one consumption has severe operational implications for system stability and data integrity. By stamping RESPONSE_PROCESSED on an unrelated next IOCB, the driver incorrectly signals to the firmware or higher-level stack that this subsequent command is complete when it may not be. Furthermore, advancing the ring pointer past this legitimate entry effectively drops a valid firmware response from the queue. This silent drop means that pending I/O operations associated with that dropped response will never receive their completion status, potentially leading to hung processes, timeouts in storage applications, or even kernel panics if critical resources are left in an inconsistent state due to unacknowledged commands.
The technical flaw also involves a failure to properly mark the head IOCB as processed. Because the pointer was advanced before consumption began, the original head entry lacked its signature update, leaving it in a limbo state where it might be re-processed or cause confusion in subsequent queue management cycles. This inconsistency violates the expected atomicity of response handling and can lead to duplicate processing attempts or memory leaks if entries are not correctly released back into the free pool after completion.
To mitigate this vulnerability, the fix involves correcting the loop logic within __qla_consume_iocb. The solution requires explicitly marking the head IOCB as processed before entering the consumption loop for continuation entries. Additionally, the iteration count must be adjusted to consume only entry_count minus one continuation IOCBs, thereby aligning the driver's behavior with that of __qla_copy_purex_to_buffer and ensuring accurate accounting of all response queue elements. This adjustment ensures that each firmware response is correctly acknowledged without encroaching on unrelated entries in the circular buffer.
From a classification perspective, this vulnerability falls under CWE-193 Off-by-One Error, as it involves an incorrect calculation leading to access one element beyond the intended boundary within the data structure. In terms of attack vectors and impact analysis aligned with MITRE ATT&CK, while primarily a stability issue rather than a direct security exploit for privilege escalation, such memory management errors can sometimes be leveraged in complex scenarios involving denial-of-service or potentially information disclosure if the dropped responses contain sensitive state information that remains accessible due to improper cleanup. However, its primary classification is as a reliability defect affecting system availability and data consistency within storage subsystems.
System administrators and users of affected Linux distributions should apply kernel updates provided by their respective vendors to patch this qla2xxx driver flaw. Regular maintenance of the operating system ensures that such low-level concurrency and logic errors are resolved, preserving the integrity of high-performance Fibre Channel storage environments dependent on precise hardware-software synchronization.