CVE-2026-98154 in Linux
Summary
by MITRE • 09/25/2026
In the Linux kernel, the following vulnerability has been resolved:
nvme-rdma: fix -EIO cleanup order in queue_rq
On -EIO, the RDMA queue_rq path reports a host path error and then still cleans up the command and unmaps the SQE DMA. The path error helper completes the request, so that is double cleanup and DMA unmap after the request is already complete.
Unmap the SQE first, then report the host path error. Skip the outer command cleanup on that path.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/25/2026
The Linux kernel's NVMe over RDMA driver contains a logic flaw in the queue_rq function related to the handling of input/output errors during asynchronous I/O operations. Specifically, when an -EIO condition is detected within this code path, the system incorrectly proceeds through a sequence that results in double cleanup and redundant DMA unmapping. The existing implementation first reports a host path error via a helper function which subsequently completes the request structure. Following this completion, the driver still executes commands to clean up the command context and unmap the Submission Queue Entry (SQE) from Direct Memory Access mappings. This sequence creates a race condition-like scenario where resources are freed twice: once implicitly through the request completion mechanism triggered by the path error reporting, and again explicitly through the subsequent cleanup routines. Such double-free or double-unmap scenarios can lead to memory corruption, kernel panics, or undefined behavior as the kernel attempts to manage already-released hardware mappings and data structures that may have been returned to the application or marked for reuse.
From a technical perspective, this vulnerability falls under CWE-415 Double Free, which occurs when software frees an object twice without ensuring it is reallocated between the two calls. In the context of NVMe over RDMA, the SQE DMA mapping represents critical hardware-software interface resources that must be managed with strict ordering to maintain data integrity and system stability. The improper order allows for a state where the request completion handler might have already invalidated or recycled certain pointers or buffers, making the subsequent explicit unmap operation dangerous. This flaw highlights a lack of proper control flow separation between error reporting paths and resource teardown logic within the driver's submission queue handling mechanism.
The operational impact of this vulnerability includes potential system instability ranging from minor I/O errors to severe kernel crashes depending on timing and memory state at the moment of execution. Attackers or automated fuzzing tools could potentially trigger these -EIO conditions repeatedly to exhaust resources, cause denial of service through kernel oopses, or exploit any side effects resulting from corrupted DMA mappings. While direct remote code execution is unlikely without additional adjacent vulnerabilities, the reliability of storage subsystems connected via RDMA is compromised, affecting data availability and integrity for workloads relying on NVMe over Fabrics.
To mitigate this issue, the recommended approach involves restructuring the error handling logic within the queue_rq function to ensure strict ordering of operations. The SQE DMA mapping must be unmapped before reporting the host path error. Furthermore, the outer command cleanup routine should be skipped entirely when entering the -EIO path because the subsequent completion and unmap actions are handled by the specialized error handling flow. This ensures that resources are freed exactly once in a deterministic order, preventing double-free conditions. System administrators should apply kernel updates containing this patch to restore proper resource management semantics for NVMe RDMA devices.
This vulnerability aligns with CWE-415 Double Free and relates to improper input validation or state management within device drivers. In terms of the MITRE ATT&CK framework, while not a direct attack technique itself, such flaws are often exploited in conjunction with other techniques like exploitation for denial of service (T1499) or potentially privilege escalation if memory corruption leads to arbitrary write primitives. Maintaining strict adherence to resource lifecycle management principles is essential for kernel-level drivers interacting directly with hardware DMA engines.