CVE-2026-99212 in Linux
Summary
by MITRE • 10/28/2026
In the Linux kernel, the following vulnerability has been resolved:
net/rds: don't let the rdma_cm destroy an id RDS still owns on route failure
rds_rdma_cm_event_handler_cmn() hands the return value of rdma_resolve_route() straight back to the rdma_cm on RDMA_CM_EVENT_ADDR_RESOLVED. A synchronous failure there - -ENOMEM from the route work allocation, an SA query that cannot be set up, a RoCE route with no usable device - makes addr_handler() destroy the id the event was delivered on. That id is ic->i_cm_id, and nothing clears the pointer: the connection sits in RDS_CONN_CONNECTING with a freed id until its shutdown calls rdma_disconnect() and rdma_destroy_id() on it.
The ROUTE_RESOLVED case already avoids this: rds_ib_cm_initiate_connect() forces a zero return while ic->i_cm_id == cm_id, as the comment there explains. Do the same here - drop the connection and return 0 - so the id stays RDS's to destroy from the shutdown, and the reconnect gets a fresh one.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/28/2026
The Linux kernel vulnerability in the Reliable Datagram Sockets (RDS) subsystem over InfiniBand presents a critical use-after-free scenario triggered during network route resolution failures. This flaw resides within the net/rds module, specifically affecting how connection management identifiers are handled when underlying RDMA Connection Manager events indicate address or route resolution errors. The core technical issue arises in the rds_rdma_cm_event_handler_cmn function, which processes asynchronous events from the RDMA subsystem. When an ADDR_RESOLVED event occurs and rdma_resolve_route returns a synchronous error such as -ENOMEM due to work allocation failure, inability to set up Service Association queries, or lack of usable RoCE devices, the current logic incorrectly propagates this return value directly back to the connection manager. This erroneous propagation causes the RDMA Connection Manager to immediately destroy the identifier associated with the event. However, RDS retains a reference to this identifier in its internal structure as ic->i_cm_id without clearing the pointer. Consequently, the kernel enters an inconsistent state where the connection object remains in the CONNECTING state but references memory that has already been freed by the RDMA subsystem.
This architectural inconsistency leads to severe operational impacts including potential kernel panics, data corruption, or privilege escalation if exploited through crafted network conditions. The vulnerability manifests when subsequent operations attempt to access the now-dangling pointer ic->i_cm_id. Specifically, during connection shutdown procedures, RDS attempts to call rdma_disconnect and rdma_destroy_id on this freed identifier. Since the memory has already been reclaimed by the RDMA layer, these calls operate on invalid memory addresses, violating kernel memory safety constraints. The issue is particularly insidious because it relies on race conditions or specific failure modes in network routing that may not be easily reproducible under normal operating conditions but can occur during high-load scenarios or when network infrastructure experiences transient faults.
The root cause analysis reveals a deviation from established patterns within the same codebase. In the ROUTE_RESOLVED case, handled by rds_ib_cm_initiate_connect(), there is an explicit safeguard that forces a zero return value while ic->i_cm_id matches the current cm_id. This design ensures that RDS retains ownership of the identifier and manages its lifecycle correctly through shutdown routines rather than allowing external subsystems to prematurely destroy it. The vulnerability exists because this protective logic was not applied consistently across all event handling paths, specifically missing in the error path for address resolution failures. By failing to drop the connection and return zero upon synchronous route failure, the code allows the RDMA layer to assume ownership of an identifier that RDS still considers active.
From a classification perspective, this vulnerability aligns with CWE-416 Use After Free, as it involves accessing memory after it has been freed by another component. It also relates to CWE-362 Concurrent Execution Using Shared Resource with Improper Synchronization, given the asynchronous nature of RDMA events and kernel state management. In terms of MITRE ATT&CK mapping, this flaw could potentially be leveraged in techniques associated with T1059 Command and Scripting Interpreter or more broadly within privilege escalation vectors if an attacker can trigger specific network conditions to induce the use-after-free condition leading to arbitrary code execution via kernel memory corruption.
Mitigation strategies should focus on applying the patch that enforces consistent ownership semantics across all RDMA event handlers. The primary fix involves modifying rds_rdma_cm_event_handler_cmn to drop the connection and return zero when rdma_resolve_route fails synchronously, mirroring the behavior already present in the route resolved path. This ensures that RDS maintains exclusive control over the lifecycle of its connection identifiers until explicit shutdown procedures are initiated by the application layer. System administrators should apply kernel updates containing this fix immediately upon availability. Additionally, monitoring for unusual network disconnection patterns or kernel oops messages related to RDMA subsystems can help detect exploitation attempts in real-time environments where patching might be delayed temporarily due to operational constraints.