CVE-2026-89845 in Linux
Summary
by MITRE • 09/16/2026
In the Linux kernel, the following vulnerability has been resolved:
scsi: qla2xxx: Avoid req_q_map double-read in qla2x00_error_entry()
qla2x00_error_entry() reads ha->req_q_map[que] twice: once for the NULL
check and again when assigning it to req. The map slot is cleared by qla25xx_free_req_que() (ha->req_q_map[que_id] = NULL under mq_lock)
during queue teardown, while the response-queue interrupt that drives qla2x00_error_entry() is still registered (the IRQ is released later in qla25xx_free_rsp_que()). If the slot is set to NULL between the two reads, req becomes NULL and is dereferenced.
Read the slot once into req and NULL-check the local before use. mq_lock is a mutex and cannot be taken from interrupt context, so the single read plus local check is the appropriate fix for the reported NULL dereference.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 09/16/2026
The Linux kernel driver qla2xxx, which manages QLogic Fibre Channel host bus adapters, contains a race condition vulnerability within its error handling logic that can lead to a null pointer dereference and subsequent system instability or crash. This issue is located in the function qla2x00_error_entry(), which serves as an interrupt handler for processing errors on SCSI request queues. The core technical flaw stems from a classic time-of-check-to-time-of-use (TOCTOU) race condition involving concurrent access to shared data structures without adequate synchronization during critical state transitions. Specifically, the code performs two separate reads of the ha->req_q_map[que] array element: first to verify that the pointer is not null and second to assign it to a local variable named req for subsequent processing. This pattern assumes atomicity in memory access but fails to account for concurrent modifications by other kernel threads or interrupt contexts operating on different parts of the driver's lifecycle management subsystem.
The vulnerability manifests during the queue teardown process, specifically when qla25xx_free_req_que() is invoked. This function clears the corresponding slot in the request queue map array by setting it to NULL while holding the mq_lock mutex. However, there exists a timing window where this cleanup occurs after the response-queue interrupt has been registered but before it has been fully unregistered and released via qla25xx_free_rsp_que(). Because the error entry handler is triggered asynchronously in response to hardware interrupts, it can execute concurrently with the queue teardown routine. If the mq_lock is held by the teardown thread at the moment of the first read check, the pointer appears valid. However, if the lock is released and the slot is cleared before the second read occurs within qla2x00_error_entry(), the local variable req will be assigned a NULL value. Subsequent code that attempts to dereference this null pointer results in an invalid memory access, typically causing a kernel panic or oops depending on the architecture and specific execution context.
From a security perspective, while this vulnerability is primarily classified as a reliability issue due to its potential to cause denial of service through system crashes, it also touches upon broader categories of software weaknesses defined by industry standards such as CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization (Race Condition). The specific nature of the bug aligns closely with CWE-476: NULL Pointer Dereference. In high-throughput storage environments where hardware interrupts are frequent and queue management operations occur regularly, this race condition is non-deterministic but reproducible under load or during normal adapter reset procedures. An attacker with local access who can trigger specific SCSI error conditions or force driver resets could potentially exploit this instability to disrupt system availability, although the primary impact remains operational rather than privilege escalation in most standard configurations.
The mitigation implemented addresses the root cause by eliminating the double-read pattern entirely. Instead of checking and then reading again, the fix involves performing a single read operation into the local req variable followed immediately by a NULL check on that local copy before any dereferencing occurs. This approach ensures consistency within the current execution context without requiring complex locking mechanisms inside interrupt handlers. It is important to note that taking the mq_lock mutex from an interrupt context is prohibited in Linux kernel programming due to potential deadlocks and scheduling restrictions, making this single-read strategy the correct architectural solution. By decoupling the validation step from a separate memory access event, the vulnerability window is closed effectively without introducing new synchronization overhead or latency issues into the high-performance path of the storage driver.
To further mitigate risks associated with similar race conditions in kernel drivers, developers should adhere to strict concurrency control practices and utilize atomic operations where appropriate for shared state variables that are accessed from both process context and interrupt handlers. Regular static analysis tools configured to detect TOCTOU vulnerabilities can help identify such patterns early in the development cycle. Additionally, ensuring proper lifecycle management of hardware resources, particularly regarding the precise ordering of registration and deregistration of interrupts relative to resource cleanup, is critical for maintaining system stability. For users running affected kernel versions, applying the upstream patch that resolves this qla2xxx issue is essential to prevent potential denial-of-service scenarios arising from null pointer dereferences during error handling sequences.