CVE-2026-89526

What it actually does

The Linux kernel NFS/RPC RDMA server (svcrdma) accepts a client-supplied Read chunk position and stores it without checking it against the received inline RPC body length. Alignment is checked, but bounds and overlap are not. In the single-chunk path this underflows the tail kvec length and exposes adjacent slab memory to the XDR decoder. In the multi-chunk and call-chunk paths, unsigned gap calculations underflow on overlapping or past-the-body positions, and svc_rdma_copy_inline_range() copies past the receive buffer into request pages that are returned on the Reply channel. The result is kernel out-of-bounds read/write: information disclosure of slab contents, memory corruption, and likely availability impact (oops/panic) in NFS-over-RDMA handling.

Why it matters to the business

Any host acting as an NFS server over RDMA can be attacked from the network without credentials. Consequences range from kernel memory leakage (keys, credentials, other tenants' data on multi-tenant file servers) to host crash and, given CVSS 9.8 with high confidentiality/integrity/availability, full compromise of the file server. That can halt shared storage, disrupt applications that depend on NFS, and provide a foothold onto backup, HPC, or virtualization infrastructure that commonly uses RDMA. The issue is not in CISA KEV, is not associated with ransomware campaigns, and has no reported exploit maturity, but it has been public for about 34 days with an unauthenticated network attack surface—treat internet- or untrusted-network-exposed NFS RDMA as urgent.

How an attack unfolds

An unauthenticated remote client that can speak RPC/RDMA to a vulnerable nfsd/svcrdma instance sends a Call with a Read chunk list whose position or overlap is inconsistent with the inline body. The kernel parses the attacker-controlled position verbatim. Reconstruction then underflows length or gap math, either feeding adjacent slab bytes into the upper XDR decoder or copying past the receive buffer into pages later sent back on the Reply channel. The attacker reads leaked kernel memory from the reply and/or corrupts kernel heap state. With a high-severity memory-corruption primitive in kernel NFS RDMA, a capable attacker can pursue further corruption toward code execution in kernel context and full control of the file server. No named threat actors or in-the-wild campaigns are associated with this CVE at publication, and exploit maturity is none, so mass exploitation is not evidenced—but the primitive is remotely reachable wherever svcrdma is exposed.

How to fix it

Apply the upstream Linux kernel fix that validates Read chunk positions before reconstruction: bound svc_rdma_copy_inline_range() against the decoded inline RPC body in rc_saved_arg; reject a single Read chunk positioned beyond that body; reject multi-chunk lists where accumulated read bytes exceed the next chunk position; apply the same position and overlap checks on the call-chunk interleaving path. Install a vendor or distribution kernel that contains this svcrdma change and reboot into it. Exact fixed package versions were not supplied with this record—use your distro security tracker for the CVE and deploy the first kernel that lists this resolution. Until patched, disable NFS-over-RDMA / svcrdma if RDMA export is not required (fall back to TCP NFS), do not expose RDMA NFS to untrusted networks, and restrict RDMA endpoints with host firewalls, network segmentation, and adapter-level access control. Do not rely on authentication of NFS clients alone: the flaw is in unauthenticated parsing of RDMA chunk metadata.

How to confirm the fix worked

Confirm the running kernel includes the svcrdma Read-chunk position validation (check distro changelog/CVE mapping or inspect that xdr_count_read_segments / svc_rdma_read_complete_one / svc_rdma_read_multiple_chunks / svc_rdma_copy_inline_range enforce bounds against rc_saved_arg). Verify svcrdma.ko / nfsd RDMA is either patched or unloaded if unused (lsmod, /proc/modules, nfsd export config, rdma ports). After patching, reboot and confirm the new kernel uname and that NFS RDMA still serves trusted clients. For exposure detection, inventory hosts with nfsd and in-kernel RPCRDMA, listening RDMA/NFS services, and any exports reachable beyond a trusted storage fabric.

Typical attack path

1. Identify Linux NFS servers with RPC-over-RDMA enabled (svcrdma/nfsd RDMA listener reachable from an untrusted network).
2. Open an RDMA connection and issue NFS/RPC Calls that include a Read chunk list.
3. Set Read chunk position and/or overlapping chunk positions so they are not bounded by the actual inline RPC body (the field is accepted with only alignment checking).
4. Trigger single-chunk tail underflow or multi-chunk unsigned gap underflow during chunk reconstruction and inline-range copy.
5. Recover adjacent kernel slab contents from the Reply channel and/or induce out-of-bounds copies into request pages.
6. Use leaked kernel memory or resulting heap corruption to crash the host or escalate to kernel-level control of the NFS server.

How to detect it

There are no public exploits or named actors to pivot from, so detection is artifact- and crash-based rather than signature-based. Review kernel logs (journalctl -k, dmesg, persistent /var/log/kern.log or equivalent) on NFS RDMA servers for oops, panic, KASAN/UBSAN, or warning stacks involving svcrdma chunk reconstruction and inline copy. Correlate timestamps with unusual RDMA/NFS client connections, especially from unexpected GIDs/IPs or short-lived connections that issued Calls then disconnected. Capture of RDMA/RPC is uncommon; if fabric logs or Soft-RoCE/iWARP logs exist, look for malformed or oversized Read-chunk lists around the same time. Memory-leak exploitation may leave no crash—treat unexplained kernel memory contents appearing in NFS replies as suspicious if you have packet captures. Absence of oops does not prove non-exploitation.

• svc_rdma_copy_inline_range
• svc_rdma_read_complete_one
• svc_rdma_read_multiple_chunks
• xdr_count_read_segments
• svcrdma
• nfsd RDMA
• Call Trace: svcrdma
• KASAN: slab-out-of-bounds
• Unable to handle kernel paging request

What your security team should do

• Patch and reboot Linux NFS RDMA servers first—prioritize any host with svcrdma/nfsd RDMA reachable from outside a dedicated storage fabric.
• Until kernels are confirmed fixed, disable svcrdma or block inbound RPC/RDMA at the fabric and host firewall so untrusted clients cannot submit Read chunk lists.
• Inventory all NFS-over-RDMA endpoints (HPC, hypervisors, backup, NAS appliances shipping this kernel) even though a packaged affected-product list was not provided.
• Hunt kernel logs for historical oops/KASAN hits in the svcrdma read-complete and inline-copy paths; treat hits as possible attempted or successful abuse.
• Do not wait for KEV or public exploits: CVSS 9.8, no privileges, network vector, and ~34 days since publication justify emergency change control for exposed file servers.