CVE-2026-89534

What it actually does

A use-after-free in the Linux kernel NFS/RPC-over-RDMA server (svcrdma) leaves sc_cm_id pointing at a connection-manager ID that the RDMA CM core is destroying when ADDR_CHANGE replacement allocation fails. Later listener teardown (for example svc_rdma_detach calling rdma_disconnect) dereferences the freed object in kernel context, enabling memory corruption that can crash the host or be turned into arbitrary kernel read/write and privilege escalation.

Why it matters to the business

Linux hosts that serve NFS or other RPC services over RDMA can be taken down or fully compromised by an unauthenticated attacker on the adjacent RDMA/LAN fabric, interrupting shared storage, HPC, and virtualization workloads. Thirty-four days after publication there is no CISA KEV listing, no ransomware use, and no reported public exploit, but CVSS 8.8 with high confidentiality, integrity, and availability impact still makes unpatched RDMA NFS servers an urgent kernel-risk for any organization running InfiniBand, RoCE, or iWARP file services.

How an attack unfolds

An attacker on the same adjacent network or RDMA fabric as a Linux system running the kernel RPC RDMA listener induces an RDMA_CM_EVENT_ADDR_CHANGE against that listener. The kernel tries to allocate a replacement cm_id and, on allocation failure, still holds a pointer to the old ID that the CM core then destroys. A subsequent detach, shutdown, or disconnect follows the dangling sc_cm_id into freed kernel memory. That use-after-free can panic nfsd/svcrdma or, with heap control, corrupt kernel objects to gain kernel privileges. No named APT groups or ransomware campaigns are associated with this CVE, and exploit maturity is none.

How to fix it

Install a Linux kernel that includes the svcrdma fix: NULL sc_cm_id when ADDR_CHANGE replacement fails, and skip rdma_disconnect in svc_rdma_detach when sc_cm_id is NULL. Use your distribution’s security kernel that lists CVE-2026-89534; no per-package fixed versions were supplied with this record, so confirm via vendor advisory or kernel changelog. If a patched kernel is not yet available, disable NFS/RPC over RDMA (do not load svcrdma/rpcrdma, stop RDMA nfsd listeners) and serve NFS over TCP/IP instead, and restrict the RDMA fabric to trusted peers only. Reboot onto the patched kernel to load the new code.

How to confirm the fix worked

Verify the running kernel’s changelog, distro CVE mapping, or svcrdma source contains the sc_cm_id NULL-on-failure and NULL-guarded rdma_disconnect changes for this issue. After upgrade, reboot, confirm uname -r matches the patched package, and that svcrdma listeners start cleanly. On hosts that should not offer RDMA NFS, confirm svcrdma/rpcrdma are not loaded (lsmod, /proc/modules) and that no RDMA NFS listeners are bound. Regression-check listener teardown and address-change handling in a maintenance window and watch dmesg for oopses in svc_rdma_detach or rdma_disconnect.

Typical attack path

1. Obtain adjacent-network or RDMA-fabric reachability to a Linux host with svcrdma/nfsd RDMA listening.
2. Trigger an RDMA address-change event on the RPC RDMA listener so replacement cm_id allocation is attempted.
3. Cause that replacement allocation to fail so sc_cm_id still references the cm_id the CM core destroys.
4. Force listener detach, disconnect, or server shutdown so rdma_disconnect runs against the freed object.
5. Use the resulting kernel use-after-free to crash the host or corrupt kernel memory for privilege escalation and persistence.

How to detect it

Review kernel logs and crash dumps (dmesg, journalctl -k, /var/log/kern.log, /var/log/messages, kdump/vmcore) for oops, KASAN use-after-free, general-protection, or NULL-pointer faults whose call traces include svcrdma, svc_rdma_listen_handler, svc_rdma_detach, or rdma_disconnect, especially around RDMA CM address-change handling. Correlate with nfsd instability, unexpected svcrdma/rpcrdma unload, and bursts of RDMA CM events. There are no public exploit payloads or named-actor IOCs; treat crashes in this path on unpatched RDMA NFS servers as potentially malicious if they coincide with unusual fabric address-change activity. Preserve vmcore and the kernel version string for later analysis.

• svc_rdma_detach
• svc_rdma_listen_handler
• svcrdma
• rdma_disconnect
• RDMA_CM_EVENT_ADDR_CHANGE
• rpcrdma
• Call Trace:.*svcrdma
• Unable to handle kernel paging request
• BUG: KASAN: use-after-free
• general protection fault
• nfsd

What your security team should do

• Inventory Linux systems with RDMA NICs and nfsd/svcrdma or sunrpc RDMA listeners and patch those kernels first.
• Treat this as high urgency despite non-KEV status: adjacent-network, unauthenticated kernel UAF at CVSS 8.8.
• If patching is delayed, disable svcrdma/RPCRDMA NFS listeners and fall back to TCP NFS; isolate the RDMA fabric.
• Subscribe to distro kernel advisories for the exact fixed package, because this record does not list version numbers.
• Alert on kernel oopses in svcrdma/svc_rdma_detach/rdma_disconnect and retain vmcore from any related crash.
• Do not expose RDMA NFS listeners to untrusted adjacent networks even after patching.