CVE-2026-89531

What it actually does

The Linux kernel NFS/RPC-over-RDMA server (svcrdma) leaks rdma_cm_id objects when transport allocation fails. handle_connect_req() returns 0 after svc_rdma_create_xprt() fails, so the RDMA Connection Manager does not destroy the new cm_id. Each failed CONNECT_REQUEST under memory pressure leaves an orphaned connection identifier in kernel memory; a remote peer that keeps issuing connection attempts can amplify the leak until RDMA CM and kernel memory resources are exhausted, producing a denial of service.

Why it matters to the business

Linux hosts that serve NFS or other RPC services over RDMA can become slow, unresponsive, or require reboot if kernel RDMA connection state grows without bound. File sharing, HPC, and clustered storage that depend on NFS/RDMA may suffer outages even without credential theft or data alteration. The issue is not in CISA KEV, is not tied to ransomware, and has no public exploit maturity about 34 days after publication, but it is still a remotely triggerable availability risk wherever svcrdma is enabled.

How an attack unfolds

An unauthenticated remote peer that can reach an RDMA-capable RPC/NFS server issues RDMA Connection Manager CONNECT_REQUEST events. When the server cannot allocate a new svcrdma transport (typically under memory pressure), the event handler still reports success, so the CM core keeps the new rdma_cm_id. Repeating connection attempts multiplies leaked identifiers until kernel memory or RDMA CM capacity is consumed and nfsd/RDMA or the host fails. No named threat actors or in-the-wild campaigns are associated with this CVE; abuse would look like a connection flood plus resource exhaustion rather than a distinct implant.

How to fix it

Install a Linux kernel that includes the upstream svcrdma fix: handle_connect_req() must return a non-zero status when svc_rdma_create_xprt() fails so the CM core destroys the orphaned rdma_cm_id. Use your distribution or vendor kernel package that contains this change and reboot into the patched kernel. Where NFS/RPC over RDMA is not required, unload or blacklist svcrdma and stop advertising NFS over RDMA. Restrict RDMA and NFS-RDMA listeners to trusted networks until all affected kernels are updated.

How to confirm the fix worked

Confirm the running kernel changelog or vendor advisory includes the svcrdma CONNECT_REQUEST rejection on transport allocation failure. On hosts that still need RDMA NFS, verify svcrdma loads only as intended and that NFS-RDMA is bound only to expected interfaces. After patching, confirm allocation failures no longer leave CM identifiers allocated (kernel/vendor test coverage or controlled connection-failure handling). Inventory unpatched kernels with svcrdma loaded as remaining exposure.

Typical attack path

1. Locate a Linux host exposing NFS or RPC over RDMA (svcrdma).
2. Reach the RDMA Connection Manager / NFS-RDMA endpoint from an untrusted network path.
3. Send repeated RDMA CONNECT_REQUEST attempts against the server.
4. Coincide with or induce transport allocation failure (memory pressure on the target).
5. Cause orphaned rdma_cm_id objects to accumulate because failed allocations are not rejected.
6. Continue until kernel memory or RDMA CM resources are exhausted and NFS/RDMA or the host becomes unavailable.

How to detect it

There is no unique payload or malware family. Hunt for already-occurred abuse by correlating NFS/RDMA servers with (1) bursts of inbound RDMA or NFS-RDMA connection attempts, (2) kernel memory or rdma_cm resource growth without matching successful sessions, (3) svcrdma/RPC-RDMA messages around failed transport creation, and (4) nfsd unavailability, reclaim, or OOM near those events. Review kernel logs (dmesg/journal), RDMA CM debug if enabled, and network telemetry to the NFS-RDMA listener. Absence of named threat actors and exploit maturity of none means treat unexplained cm_id accumulation plus connection floods as the primary signal, not a file hash or C2 indicator.

• svcrdma
• svc_rdma_create_xprt
• handle_connect_req
• rdma_cm_id
• nfsrdma
• :20049
• rpc-rdma

What your security team should do

• Patch and reboot Linux NFS/RPC RDMA servers to a kernel that rejects svcrdma connections when transport allocation fails.
• Inventory hosts with svcrdma loaded or nfsrdma enabled and prioritize internet- or untrusted-network-facing systems.
• Disable or blacklist svcrdma where NFS over RDMA is unused.
• Limit RDMA and NFS-RDMA (typically port 20049) to trusted networks and hosts.
• Watch kernel memory, slab, and RDMA CM resource growth on remaining RDMA NFS servers until the fleet is patched.
• Track distribution kernel advisories; this CVE is not KEV-listed and has no known in-the-wild exploitation, but treat it as a remote DoS until remediated.