CVE-2026-89535

What it actually does

A use-after-free race in the Linux kernel NFS server RDMA transport (svcrdma) frees an RDMA connection-manager identifier (cm_id) via rdma_destroy_id() while the transport’s notification entry remains installed in the InfiniBand device xarray. A concurrent ib_unregister_device walk can then dispatch svc_rdma_xprt_done() against the already-freed cm_id, corrupting kernel memory. Impact includes kernel oops/panic (availability), potential disclosure of kernel memory, and, if the dangling object is reused with attacker-influenced content, arbitrary execution in kernel context. Attack complexity is high because exploitation depends on winning a teardown-versus-device-unregistration race; no privileges or user interaction are required when the RDMA/NFS path is network-reachable. A related NULL-cm_id path in svc_rdma_free() can also fault if unguarded.

Why it matters to the business

Hosts that export or serve NFS over RDMA (InfiniBand, RoCE, or iWARP) can be crashed or, in a worst case, fully compromised at kernel level, taking down shared file services and any workloads on the same machine. The issue is not in CISA KEV, is not associated with ransomware campaigns, and has no reported in-the-wild exploitation about a month after publication, which lowers immediate operational urgency relative to actively exploited kernel bugs. The 8.1 network-facing score and complete confidentiality/integrity/availability impact still justify prompt kernel updates on RDMA-enabled NFS infrastructure, because a successful race yields host takeover rather than a contained application fault.

How an attack unfolds

An unauthenticated actor who can reach an NFS-over-RDMA service, or who can otherwise induce RDMA connection teardown together with InfiniBand device unregistration, targets the window inside svc_rdma_free() after rdma_destroy_id() has freed sc_cm_id but before rpcrdma_rn_unregister() removes the transport from the device notification xarray. Forcing that concurrency causes the kernel to invoke svc_rdma_xprt_done() on a dangling cm_id. The resulting use-after-free of kernel RDMA objects is then used to crash the host or to corrupt allocator state for kernel-context code execution. Timing, allocator layout, and the ability to trigger device unregistration make this a high-complexity attack; there are no named threat actors or public exploit artifacts associated with this flaw.

How to fix it

Apply the Linux kernel security update that reorders rpcrdma_rn_unregister() to run before rdma_destroy_id() in svc_rdma_free() and that NULL-checks sc_cm_id before dereference. Use the vendor or distribution kernel package that contains that svcrdma change; rebuild custom kernels from a tree that includes the fix. Until patched, disable NFS-over-RDMA where it is not required (do not load svcrdma, do not enable RDMA NFS exports/listeners), restrict who can reach the RDMA fabric and NFS-RDMA ports, and avoid RDMA device hot-unplug or driver unbind on NFS-RDMA servers during production. No specific upstream version numbers were supplied with this record, so confirm the fix via vendor advisory or kernel changelog rather than a version string alone.

How to confirm the fix worked

Confirm the running kernel (uname -r and vendor package changelog) includes the svcrdma reorder of rpcrdma_rn_unregister before rdma_destroy_id and the sc_cm_id NULL guard. Check whether svcrdma is loaded (lsmod) and whether NFS is exported or listening over RDMA. After patching, restart NFS/RDMA services and exercise connect, disconnect, listener failure, and RDMA device unbind/unplug paths without oops. Unpatched exposure is indicated by an older svcrdma.ko that still unregisters the notification after destroying the cm_id.

Typical attack path

1. Locate a Linux NFS server with svcrdma in use and RDMA (InfiniBand/RoCE/iWARP) reachable from the attacker’s network path
2. Cause NFS/RDMA transports to be created so live cm_id and notification-xarray entries exist
3. Induce concurrent transport teardown (svc_rdma_free / rdma_destroy_id) and RDMA device unregistration (ib_unregister_device)
4. Win the race so a device-notification callback runs against the freed cm_id
5. Turn the use-after-free into a kernel oops (denial of service) or controlled kernel-memory corruption
6. If corruption is converted to kernel execution, take over the NFS server host

How to detect it

There are no public exploits, named actors, or ransomware associations, so look for failed or opportunistic attempts via kernel failure artifacts rather than malware hashes. Review dmesg, journalctl -k, /var/log/kern.log, netconsole, and kdump/vmcore from NFS-RDMA hosts around connection teardown, listener failures, ADDR_CHANGE handling, and RDMA device unbind or ib_unregister_device. Hunt for oops/panic, general-protection faults, or paging requests with svcrdma, svc_rdma_free, svc_rdma_xprt_done, rpcrdma_rn_unregister, or rdma_destroy_id on the stack. Correlate with RDMA device removal, nfsd/svcrdma module unload, and abrupt NFS-RDMA disconnects. Absence of those traces does not prove the race was never attempted; it only means it did not crash the box.

• svc_rdma_xprt_done
• svc_rdma_free
• rpcrdma_rn_unregister
• rdma_destroy_id
• svcrdma
• BUG: unable to handle kernel paging request
• general protection fault
• kernel BUG at
• ib_unregister_device
• Call Trace:.*svcrdma
• nfsd.*svcrdma

What your security team should do

• Patch Linux kernels on NFS-over-RDMA servers first; treat remaining RDMA-capable NFS hosts as the next wave even though this CVE is not in KEV
• Inventory systems with svcrdma loaded or NFS RDMA exports/listeners and isolate or disable RDMA NFS until those kernels are updated
• Restrict RDMA fabric and NFS-RDMA network access to trusted clients only as a compensating control
• Enable kdump/vmcore collection and kernel-oops alerting on NFS-RDMA hosts so a failed race still produces forensic evidence
• Reassess after vendor kernels ship: this issue has no known exploit maturity, so prioritize relative to KEV and mass-scanned flaws, but do not defer RDMA NFS servers indefinitely given CVSS 8.1 kernel impact