CVE-2026-89853 in Linux
Summary
by MITRE • 09/16/2026
In the Linux kernel, the following vulnerability has been resolved:
scsi: qla2xxx: Fix FCE trace use-after-free during firmware dump
qla2x00_free_fce_trace() freed and cleared ha->fce while holding only fce_mutex. The firmware-dump consumers qla27xx_fwdt_entry_t264() and qla25xx_copy_fce() read ha->fce (NULL check followed by a copy of the buffer) under hardware_lock and never take fce_mutex. A debugfs FCE disable could therefore free the DMA buffer between a dump's NULL check and its copy, resulting in a use-after-free.
Unpublish ha->fce under hardware_lock, then release the lock and free the DMA buffer (dma_free_coherent() may sleep). A concurrent dump either completes its check and copy with the buffer still valid, or observes ha->fce == NULL and skips it.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/16/2026
The Linux kernel vulnerability identified in the qla2xxx SCSI driver involves a critical use-after-free condition within the Fibre Channel Event (FCE) trace handling mechanism during firmware dump operations. This flaw stems from an inconsistent locking strategy that fails to protect shared data structures against concurrent access, leading to potential memory corruption and system instability. The root cause lies in the qla2x00_free_fce_trace function, which frees and clears the ha->fce pointer while holding only the fce_mutex. However, other components of the driver responsible for consuming firmware dump data, specifically qla27xx_fwdt_entry_t264 and qla25xx_copy_fce, access this same ha->fce structure under a different lock context known as hardware_lock. These consumer functions perform a NULL check on ha->fce followed by copying the buffer contents but do not acquire fce_mutex during these operations. This discrepancy creates a race condition where the DMA buffer associated with FCE traces can be freed and its memory returned to the system allocator between the time a consumer checks for validity and when it attempts to copy the data, resulting in a use-after-free vulnerability that compromises kernel integrity.
From a technical perspective, this issue represents a classic synchronization error where multiple execution paths access shared resources without consistent mutual exclusion guarantees. The hardware_lock is typically used to protect against concurrent hardware operations and immediate state changes, while fce_mutex was intended for serializing trace management activities. By not holding the same lock during both the check-and-copy sequence in consumers and the free operation in the cleanup routine, the driver allows a window of vulnerability where memory safety cannot be guaranteed. This type of flaw is particularly dangerous because it may not manifest immediately under light load but can trigger sporadically when firmware dumps are triggered concurrently with trace management operations, such as disabling FCE via debugfs interfaces. The use-after-free condition could lead to arbitrary code execution if an attacker can control the contents written into the freed memory region before it is reallocated for another purpose, or cause kernel panics due to invalid memory accesses.
The operational impact of this vulnerability extends beyond immediate system crashes to include potential security breaches and data integrity issues in enterprise storage environments utilizing QLogic Fibre Channel adapters. Firmware dumps are often used for debugging critical hardware failures, meaning that the affected code paths may be exercised during incident response scenarios when systems are already under stress or experiencing errors. An attacker with local access who can trigger firmware dump operations while simultaneously manipulating FCE trace settings could exploit this race condition to escalate privileges or destabilize the host system. In high-availability storage networks, such instability could lead to unplanned downtime and disruption of critical business services dependent on reliable SCSI over Fibre Channel connectivity. The vulnerability affects systems where qla2xxx drivers are compiled with debugfs support enabled, allowing userspace interaction with FCE trace controls.
To mitigate this risk, the resolution involves restructuring the locking logic to ensure atomicity between checking for buffer validity and freeing it. Specifically, the ha->fce pointer must be unpublished or cleared while holding hardware_lock rather than fce_mutex before releasing the lock and proceeding with memory deallocation via dma_free_coherent. This approach ensures that any concurrent consumer thread either completes its NULL check and subsequent copy operation while the buffer is still valid, or observes a NULL value indicating that the resource has already been released safely. Since dma_free_coherent may sleep during execution, it must be called after releasing hardware_lock to prevent potential deadlocks with other hardware-lock-protected sections of code. This fix aligns with best practices for kernel synchronization by ensuring that all access points to shared data structures use a consistent locking hierarchy and that state transitions are performed atomically relative to consumer checks.
This vulnerability maps directly to CWE-416, Use After Free, which describes the error condition where software continues to use memory after it has been freed, leading to undefined behavior. Additionally, from an offensive security standpoint as defined by MITRE ATT&CK, this flaw could be leveraged in techniques related to Privilege Escalation via Memory Corruption or Defense Evasion through System Process Disruption. Security practitioners should verify that the qla2xxx driver is updated with patches addressing this locking inconsistency and consider disabling debugfs interfaces on production systems unless strictly necessary for troubleshooting. Regular auditing of kernel lock usage patterns and employing static analysis tools capable of detecting race conditions can help identify similar synchronization issues in other parts of the storage stack before they are exploited in real-world scenarios.