CVE-2026-89532

What it actually does

An unsigned integer underflow in the Linux kernel NFS/RDMA server (svcrdma) macro pcl_for_each_segment treats a Write or Reply chunk with ch_segcount==0 as an inclusive upper bound of ch_segments[0xFFFFFFFF]. The loop then walks far past the chunk's flex array at sizeof(struct svc_rdma_segment) stride. When Send-With-Invalidate is negotiated, svc_rdma_get_inv_rkey iterates all PCLs and dereferences segment->rs_handle, turning the wrap into an out-of-bounds kernel read and a general protection fault. Confidentiality (kernel memory disclosure) and availability (host oops/panic) are affected; integrity and code execution are not indicated.

Why it matters to the business

Unauthenticated network attackers can crash Linux NFS-over-RDMA servers and may expose kernel memory, taking high-performance storage, HPC, and other NFSoRDMA-backed workloads offline until the host is recovered. CVSS 9.1 with network reachability and no privileges or user interaction means a single crafted RPC/RDMA message can interrupt production file service. The issue has been public for 34 days with no KEV listing, no ransomware use, and no known exploit maturity, but the kernel-level DoS and leak potential still warrant urgent patching wherever svcrdma is enabled.

How an attack unfolds

An attacker who can reach a Linux NFS server with the RDMA transport (svcrdma) enabled establishes an RPC/RDMA session that negotiates Send-With-Invalidate. They send a Write or Reply chunk list that advertises a chunk with zero segments. Kernel XDR checks only reject segment counts above rc_maxpages, so a zero count is accepted; pcl_alloc_write allocates a chunk with ch_segcount still 0 and links it onto rc_write_pcl or rc_reply_pcl before the fill loop (which runs zero times). Later, svc_rdma_get_inv_rkey walks every PCL with pcl_for_each_segment. For the empty chunk the inclusive bound wraps a u32 subtraction to 0xFFFFFFFF, the loop body reads unrelated kernel memory via rs_handle, and the host takes a general protection fault. The attacker obtains a reliable remote crash and, depending on what is read before the fault, may observe leaked kernel contents. No named threat actors or in-the-wild campaigns are associated with this issue.

How to fix it

Apply a Linux kernel update that includes the svcrdma fix: pcl_for_each_segment must use a half-open upper bound based on ch_segcount directly so a zero-segment chunk is a no-op instead of wrapping to 0xFFFFFFFF. Existing call sites in net/sunrpc/xprtrdma/svc_rdma_recvfrom.c and svc_rdma_rw.c do not require separate caller changes. Until the patched kernel is running, disable NFS-over-RDMA / unload svcrdma and xprtrdma if the service is not required, and restrict RDMA and NFS listeners to trusted fabrics. Reboot onto the patched kernel; there is no userspace-only workaround. Exact distro package versions were not supplied—use vendor kernel advisories that reference this svcrdma empty-chunk fix.

How to confirm the fix worked

Confirm the running kernel includes the half-open pcl_for_each_segment bound (ch_segcount used directly; empty chunks skip the loop). Inventory NFSoRDMA exposure: loaded svcrdma/xprtrdma/rpcrdma modules, nfsd RDMA listeners, and kernel config options such as CONFIG_SUNRPC_XPRT_RDMA / NFSD RDMA. After patching, boot the new kernel, verify uname -r against the advisory, and ensure svcrdma is the updated build. Spot-check that RDMA NFS still functions for legitimate clients and that empty or malformed chunk lists no longer oops the host. Hosts without RDMA NFS loaded are not exposed to this path.

Typical attack path

1. Locate Linux NFS servers exposing the RDMA transport (svcrdma) on the RDMA fabric or related NFS/RDMA listeners.
2. Complete RPC/RDMA connection setup so Send-With-Invalidate is negotiated.
3. Deliver a Write or Reply chunk list containing a chunk whose advertised segment count is zero (accepted because checks only cap the maximum, not the minimum).
4. Cause the server to collect invalidation rkeys, so pcl_for_each_segment walks the empty chunk and underflows its bound.
5. Trigger an out-of-bounds kernel read of svc_rdma_segment fields (rs_handle), producing a GPF/oops and possible disclosure of adjacent kernel memory, denying NFS/RDMA service.

How to detect it

This bug leaves kernel-crash artifacts rather than a distinct userspace implant. Search dmesg, journalctl -k, /var/log/kern.log, /var/log/messages, kdump/vmcore, and panic console logs for general protection faults or oopses whose RIP or call trace includes svcrdma, especially svc_rdma_get_inv_rkey, pcl iteration, or net/sunrpc/xprtrdma/svc_rdma_recvfrom.c and svc_rdma_rw.c. Correlate timestamps with unexpected RPC/RDMA clients, Send-With-Invalidate sessions, and NFS RDMA traffic. A GPF while walking chunk lists after a zero-segment Write/Reply chunk is consistent with exploitation or accidental trigger; absence of such oopses does not prove the host was never probed, only that a faulting iteration may not have completed. Review NFS/RDMA connection logs and fabric logs for anomalous clients around any svcrdma crash. No named APT tooling is documented for this CVE.

• svc_rdma_get_inv_rkey
• svcrdma
• net/sunrpc/xprtrdma/svc_rdma_recvfrom
• net/sunrpc/xprtrdma/svc_rdma_rw
• pcl_for_each_segment
• general protection fault
• Call Trace:.*svcrdma
• RIP:.*svc_rdma
• xprtrdma
• Oops:.*svcrdma

What your security team should do

• Patch and reboot Linux NFS RDMA servers first: CVSS 9.1, unauthenticated remote kernel OOB read and crash, public for 34 days.
• Inventory every host with svcrdma, xprtrdma, or nfsd RDMA enabled; treat those as in-scope even if not in CISA KEV.
• If NFSoRDMA is unused, blacklist/unload svcrdma and related RDMA RPC modules to remove the attack surface immediately.
• Limit RDMA and NFS service reachability to trusted networks/fabrics until kernels are confirmed patched.
• Watch kernel logs and crash dumps for svcrdma GPFs (especially svc_rdma_get_inv_rkey) as a sign of probing or pre-patch crashes.
• Track vendor kernel advisories for the exact package that contains this pcl_for_each_segment fix; exploit maturity is currently None, so prioritize patching over emergency hunting unless oops evidence appears.