CVE-2026-89527

What it actually does

The Linux kernel NFS/RPC RDMA server (svcrdma) frees a listener transport with kfree() when RDMA listen-ID creation fails. svc_xprt_init() has already taken a tracked network-namespace reference, so skipping svc_xprt_free()/svc_rdma_free() leaks that netns reference. The same error path can also double-drop the module reference, leaving svcrdma’s module lifetime incorrect. The result is a kernel resource-management defect (leak and refcount imbalance) on the NFS RDMA listener create-failure path, classified as denial of service rather than code execution.

Why it matters to the business

Hosts that serve NFS over RDMA can leak kernel resources when RDMA listeners fail to start, which may pin network namespaces so they cannot be destroyed, block clean module unload, or degrade the NFS RDMA service over time. Systems that do not use in-kernel NFS RDMA are not affected. This CVE is not in CISA KEV, is not associated with ransomware, and has no known exploit maturity. It was published about 34 days ago, so treat it as a standard kernel hygiene patch rather than an emergency mass-exploitation event.

How an attack unfolds

There is no public exploit and no named threat-actor or ransomware use. Abuse requires the ability to drive the in-kernel NFS RDMA listener create path so that svc_rdma_create() fails after the transport is initialized (for example, RDMA CM listen-ID creation fails). Each failed attempt can leak a network-namespace reference and unbalance the svcrdma module refcount. That typically implies local or administrative control over NFS/RDMA service setup, not unauthenticated remote code execution. Repeated triggering of the error path can accumulate leaks until namespace teardown hangs or related kernel resources are exhausted, producing a denial of service.

How to fix it

Install a Linux kernel that includes the svcrdma fix replacing kfree() with svc_xprt_put() on listener create failure, plus the compensating module-get so module refcounts stay balanced. Follow your distribution’s kernel advisory and reboot into the patched kernel. If NFS over RDMA is not required, do not load svcrdma and do not configure RDMA NFS listeners as a compensating control. No exact package versions were supplied with this record; use vendor/distro changelogs that cite this CVE or the upstream message “svcrdma: Use svc_xprt_put to free listener on create failure.”

How to confirm the fix worked

Confirm the running kernel changelog or stable commit contains the svcrdma listener-create cleanup (svc_xprt_put instead of kfree on create failure). After patching and reboot, uname/kernel package version should match the fixed release. On remaining unpatched hosts, check whether svcrdma is loaded and whether NFS RDMA listeners are configured. After the fix, failed RDMA listen setup should no longer pin net namespaces or leave svcrdma’s module refcount unbalanced, and netns teardown should still complete.

Typical attack path

1. Identify a host running the in-kernel NFS server with the RDMA transport (svcrdma) available.
2. Obtain sufficient privilege to configure or restart NFS RDMA listeners.
3. Cause RDMA listener creation to fail after transport initialization (missing or unusable RDMA device, CM listen failure, or similar setup error).
4. Repeat the failed create path to leak netns references and unbalance module refcounts.
5. Induce operational impact via stuck network-namespace teardown, resource exhaustion, or inability to unload/restart the RDMA NFS path.

How to detect it

No in-the-wild exploitation, KEV listing, or named threat actors are associated with this issue, so hunt for exposure and error-path symptoms rather than attacker tooling. Review kernel logs (dmesg, journald/kern) around NFS RDMA listener start/restart for svcrdma create/listen failures. Check whether the svcrdma module is loaded, whether nfsd was started with an RDMA transport, and whether network namespaces used by NFS fail to exit or remain stuck after failed RDMA listen attempts. Module unload failures for svcrdma and unexplained netns teardown hangs on NFS RDMA hosts are the most relevant artifacts. Absence of svcrdma and of RDMA NFS listeners indicates the host was likely not exposed.

What your security team should do

• Inventory hosts that load svcrdma or serve NFS over RDMA and patch those first.
• Apply vendor kernel updates that include this svcrdma create-failure cleanup and reboot.
• If NFS RDMA is unused, prevent svcrdma from loading and remove RDMA NFS listener configuration.
• Watch for stuck network-namespace destruction and repeated NFS RDMA listen-setup failures as residual exposure signals.
• Do not treat this as a KEV-driven emergency; track it as a kernel DoS/resource-leak fix with no known in-the-wild exploitation.