CVE-2026-92488 in Linux
Summary
by MITRE • 09/17/2026
In the Linux kernel, the following vulnerability has been resolved:
RDMA/erdma: complete object teardown when the destroy command fails
erdma_destroy_qp(), erdma_destroy_cq(), erdma_dereg_mr(), and erdma_destroy_ah() returned early when erdma_post_cmd_wait() failed, leaking the queue buffers, MTTs, doorbells and the STAG, QPN, CQN and AHN identifiers. A command timeout clears ERDMA_CMDQ_STATE_OK_BIT and permanently disables the command queue, so no retry can succeed; the RDMA core keeps the object after a failed destructor and forced uverbs cleanup then nulls the pointers, making the resources unreachable.
Warn on failure but release every software-owned resource and return success, since during terminal destruction the hardware command result is only diagnostic.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 09/18/2026
The Linux kernel's RDMA/erdma driver contained a critical resource management flaw within its object teardown routines, specifically affecting queue pair (QP), completion queue (CQ), memory region deregistration, and address handle destruction functions. When these destroy commands encountered an error during the execution of erdma_post_cmd_wait(), the implementation would return early without fully releasing associated hardware and software resources. This premature exit resulted in significant resource leaks, including queue buffers, Memory Translation Tables (MTTs), doorbell registers, and critical identifiers such as the Shared Transport Address Tag (STAG), Queue Pair Number (QPN), Completion Queue Number (CQN), and Address Handle Number (AHN). These leaked objects remain allocated within the kernel space even after the user-space application has terminated or attempted to clean up its context.
The operational impact of this vulnerability is compounded by the behavior of the underlying hardware command queue mechanism. A command timeout causes the ERDMA_CMDQ_STATE_OK_BIT flag to be cleared, which permanently disables the command queue for that device instance. Because the command queue becomes non-functional after such a failure, any subsequent attempts to retry or properly clean up these resources via standard commands will inevitably fail. Consequently, while the RDMA core retains ownership of the object following a failed destructor call and forces user-space interface cleanup by nullifying pointers, the actual kernel-level resources remain allocated but unreachable. This creates a state where system memory and hardware identifiers are consumed without being freed, leading to potential resource exhaustion over time or during repeated operations involving these objects.
From a security perspective, this issue aligns with CWE-401, which describes missing release of memory after successful allocation, and CWE-772, referring to missing release of operating system resources. The inability to properly reclaim hardware identifiers like QPNs and CQNs can lead to Denial of Service conditions as the device's capacity for managing new connections or operations diminishes with each leaked object. Furthermore, if an attacker can trigger these failure states repeatedly through crafted RDMA commands that induce timeouts, they may accelerate resource depletion on the host system, potentially impacting other services running on the same hardware platform.
The resolution involves modifying the teardown logic to ensure comprehensive cleanup regardless of the outcome of the final command submission wait operation. The updated implementation now warns upon detecting a failure but proceeds to release all software-owned resources before returning success. This approach is justified by the understanding that during terminal destruction, the result from the hardware command queue serves primarily as diagnostic information rather than a strict gatekeeper for cleanup actions. Since the object is being destroyed and will no longer be used, ensuring that all associated kernel structures are freed prevents leaks even if the hardware communication channel has already failed or been disabled by prior errors.
To mitigate similar issues in broader RDMA implementations, developers should adhere to robust error handling practices where resource deallocation is decoupled from command submission success when dealing with final object destruction phases. Adhering to ATT&CK techniques related to resource hijacking and persistence through system exploitation highlights the importance of ensuring that temporary states or errors do not leave persistent artifacts in memory. System administrators should monitor for signs of RDMA driver instability, such as unexpected device resets or inability to create new QPs/CQs after previous operations have failed, which may indicate underlying cleanup deficiencies like those previously present in erdma drivers. Regular updates to the Linux kernel and associated hardware abstraction layers are essential to maintain system stability and prevent resource exhaustion attacks targeting network interface controllers with RDMA capabilities.