CVE-2026-99212
NoneCVSS
—
EPSS
0.2%
Published
Oct 28, 2026
CISA due date
—
Cloudanix analysis
A recently fixed flaw in Linux kernel networking code for certain high-speed socket types could let an attacker crash the system or potentially take control if they can interfere with network route setup.
- Exploitation
- Local Privilege
- Attacker needs
- Local User
- Complexity
- High
- Impact
- Privilege Gain
- Component
- OS kernel
- Class
- Use After Free
- Remediation
- Upgrade
- Effort
- Medium
- Patch risk
- Low
What it actually does
Use-after-free on the RDMA cm_id pointer (ic->i_cm_id) in RDS connection state machine: synchronous rdma_resolve_route failure in rds_rdma_cm_event_handler_cmn causes rdma_cm to destroy the id while RDS leaves the pointer dangling in RDS_CONN_CONNECTING state, later dereferenced by shutdown paths calling rdma_disconnect/rdma_destroy_id.
Why it matters to the business
Kernel memory corruption risk on Linux systems using RDS over RDMA (common in Oracle RAC, high-performance storage, and InfiniBand/RoCE fabrics); published one day ago with no known exploitation, low immediate operational urgency but high priority for clusters relying on RDS reliability.
How an attack unfolds
An attacker with network adjacency or local access manipulates RDMA address resolution to force synchronous failures (ENOMEM, SA query errors, or unusable RoCE devices) during RDS connect; the resulting dangling pointer is later used on connection teardown, enabling memory corruption that may be chained into privilege escalation or denial of service.
How to fix it
Apply the upstream kernel patch that returns zero from the ADDR_RESOLVED handler on failure (matching the existing ROUTE_RESOLVED logic) and upgrade to a fixed kernel release; disable RDS/RDMA interfaces where not required.
How to confirm the fix worked
Inspect kernel source or running system for the corrected rds_rdma_cm_event_handler_cmn logic ensuring cm_id ownership is not transferred on synchronous route failure; confirm via kernel version string or by reproducing connect failures without subsequent use-after-free oops.
Typical attack path
- Establish or trigger an RDS/RDMA connection attempt
- Induce route resolution failure via network conditions or resource exhaustion
- Allow rdma_cm to free the cm_id while RDS retains the pointer
- Force connection shutdown to dereference the freed id
- Leverage resulting UAF for kernel memory control or crash
How to detect it
Monitor kernel logs (dmesg, /var/log/kern.log) for RDS or rdma_cm related oops, warning messages about freed cm_id, or use-after-free stack traces on systems performing RDS connections; correlate with network events showing repeated route resolution failures.
What your security team should do
- Prioritize kernel updates for any hosts exposing RDS over RDMA within the next patching cycle
- Review and restrict RDS socket usage to trusted networks only
- Enable kernel hardening features such as KASAN or hardened usercopy in test environments to surface latent UAFs
The record
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.
Affected packages
| Ecosystem | Package | Introduced | Fixed |
|---|