CVE-2026-90202 in Linux
Summary
by MITRE • 09/17/2026
In the Linux kernel, the following vulnerability has been resolved:
scsi: mpt3sas: Avoid freeing unallocated PCIe SGL buffers
_base_release_memory_pools() unconditionally frees every ioc->pcie_sg_lookup[] entry, including ones the setup loop never
allocated after a partial failure, causing a "bad dma" warning on debug kernels or a NULL pointer dereference otherwise.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/18/2026
The Linux kernel vulnerability identified in the mpt3sas SCSI driver involves an improper resource management flaw within the base release memory pools function. Specifically, the _base_release_memory_pools routine performs unconditional deallocation of every entry found in the ioc->pcie_sg_lookup array without verifying whether those specific entries were successfully allocated during the initialization phase. This logic error stems from a failure to track allocation status accurately when setup operations encounter partial failures or interruptions. Consequently, memory regions that were never assigned are targeted for freeing by the kernel's DMA subsystem, leading to severe stability issues and potential security implications due to invalid memory access patterns.
From a technical perspective, this flaw represents an out-of-bounds write or use-after-free scenario depending on how the unallocated entries map to physical memory addresses. When the driver attempts to free these non-existent buffers, it triggers a bad DMA warning in debug-enabled kernels because the hardware cannot perform direct memory access on invalid descriptors. In production environments where debugging is disabled, this condition typically results in a NULL pointer dereference or corruption of kernel heap structures as the system tries to release memory that does not belong to the current allocation context. This behavior violates fundamental principles of safe resource handling and indicates a lack of proper state tracking during driver initialization sequences.
The operational impact of this vulnerability is significant, particularly for systems relying on high-performance SCSI over PCIe storage solutions using LSI/Mellanox adapters supported by mpt3sas. An attacker with local access could potentially exploit this race condition or error path to crash the system via a denial-of-service attack caused by kernel panic from NULL pointer dereference. Furthermore, if the corrupted memory structures overlap with sensitive data or control flow pointers, there may be opportunities for privilege escalation through heap exploitation techniques. The vulnerability affects systems where device initialization fails partially but continues enough to reach the cleanup phase, making it exploitable under specific hardware configuration scenarios rather than universally across all deployments.
This issue aligns closely with CWE-416 Use After Free and CWE-787 Out-of-bounds Write vulnerabilities as defined by Common Weakness Enumeration standards. The root cause lies in insufficient validation of allocation states before performing deallocation operations, which is a classic example of improper error handling leading to resource corruption. In terms of MITRE ATT&CK framework classification, this falls under Defense Evasion techniques involving memory manipulation and potentially Impact categories related to Denial of Service through system instability. The lack of bounds checking on the pcie_sg_lookup array entries exacerbates the risk by allowing access beyond intended allocation boundaries.
Mitigation strategies primarily involve applying vendor-provided kernel patches that correct the logic within _base_release_memory_pools to verify allocation status before attempting free operations. Administrators should ensure their systems are updated with the latest stable Linux kernels containing fixes for mpt3sas driver issues. Additionally, enabling strict debugging features in test environments can help identify similar resource management flaws early in development cycles. For production systems not yet patched, monitoring kernel logs for bad DMA warnings or unexpected panics related to SCSI subsystems provides an indicator of compromise attempts targeting this specific code path. Long-term remediation requires implementing robust state tracking mechanisms during driver initialization to ensure that only successfully allocated resources are subject to cleanup procedures.