CVE-2026-89530

What it actually does

The Linux kernel RPC-over-RDMA server (svcrdma) linearizes oversized inline replies into a fixed-size pull-up buffer (sc_max_req_size) when the reply needs more scatter/gather entries than the RDMA device Send Queue supports. svc_rdma_xb_linearize() then writes past the end of sctxt->sc_xprt_buf, corrupting adjacent slab objects, and posts an SGE whose length exceeds the mapped region so the RNIC also DMA-reads out of bounds. The result is a kernel heap/slab overflow plus an unbounded device read on the NFS/RDMA reply path.

Why it matters to the business

Any Red Hat Enterprise Linux 8, 9, or 10 host acting as an NFS (or other RPC) server over RDMA can be taken down or fully compromised from the network with no credentials and no user action. Consequences include kernel panic and storage-service outage, leak of kernel memory, and potential kernel-level code execution on file servers that use InfiniBand, RoCE, or iWARP. The issue is not in CISA KEV, is not tied to ransomware, and has no public exploit 34 days after publication, but the unauthenticated network, high-integrity kernel impact still justifies treating RDMA-enabled NFS servers as urgent to patch.

How an attack unfolds

An unauthenticated peer that can send RPC-over-RDMA to a kernel NFS server crafts a call that demands a large reply (commonly an NFS READ payload) but supplies neither a Write list nor a Reply chunk. When that reply exceeds the device SGE budget, the server takes the pull-up path and copies the entire reply into a buffer sized only for maximum requests. The copy overruns slab memory and the subsequent RDMA Send reads past the mapped buffer. The attacker can use the resulting kernel memory corruption or RNIC over-read to crash the host or, with further heap-shaping, attempt privilege escalation to kernel context. No named threat actors or in-the-wild campaigns are associated with this flaw.

How to fix it

Apply the Red Hat kernel updates in RHSA-2026:77500: RHEL 10 kernel 6.12.0-211.64.1.el10_2; RHEL 9 kernel 5.14.0-687.56.1.el9_8; RHEL 8 kernel 4.18.0-553.172.1.el8_10; RHEL 8 real-time kernel-rt 4.18.0-553.172.1.rt7.513.el8_10. Reboot into the new kernel. If you cannot patch immediately, disable NFS/RPC-over-RDMA (do not load svcrdma / rpcrdma, and stop advertising nfsrdma) and serve NFS only over TCP/UDP until the fixed kernel is running. Upstream, the helper now returns -E2BIG and fails the call with ERR_CHUNK instead of overflowing.

How to confirm the fix worked

Confirm uname -r matches a listed fixed build (or later) for the installed RHEL major and that the running image is that kernel after reboot. On still-vulnerable hosts, check that svcrdma/rpcrdma are loaded and that nfsd is exporting over RDMA (nfsstat/rpcinfo for nfsrdma, rdma devices present). After patching, a reply that cannot fit sc_max_req_size should be rejected with an RDMA ERR_CHUNK-style failure rather than a kernel oops; do not use crafted overflow payloads to test. Review package changelog for the svcrdma pull-up / -E2BIG fix.

Typical attack path

1. Locate a Linux NFS or RPC server that advertises RPC-over-RDMA (portmapper/nfsrdma, InfiniBand/RoCE/iWARP).
2. Open an RDMA connection and issue an RPC that requests a large inline reply without a Write list or Reply chunk.
3. Force the SGE-exhaustion pull-up path so the kernel linearizes the reply into the undersized sc_xprt_buf.
4. Trigger slab overflow and an over-length RDMA Send against adjacent kernel memory.
5. Use the crash for denial of service or attempt to convert the heap corruption into kernel code execution and persistence.

How to detect it

There is no public exploit and no associated threat actors, so look for crash and memory-corruption evidence rather than a known implant. On NFS/RDMA servers, search kernel logs (journald, /var/log/messages, kdump/vmcore) around the publication window and any unexplained nfsd outages for oops/panic in svcrdma reply pull-up, slab redzone or out-of-bounds reports, and RDMA Send completions with unexpected lengths. Capture whether rpcrdma/svcrdma were loaded and whether clients issued large READ-like RPCs without Write lists or Reply chunks. Preserve vmcores if slab corruption or an RNIC read beyond a mapped SGE is suspected. Network traces of RPC-over-RDMA showing oversized inline replies with empty Write/Reply chunk lists are supporting context, not proof of exploitation.

• svc_rdma_pull_up_reply_msg
• svc_rdma_xb_linearize
• svc_rdma_pull_up_needed
• svcrdma
• rpcrdma
• slab-out-of-bounds
• Redzone overwritten
• Oops:.*svcrdma
• nfsrdma
• ERR_CHUNK

What your security team should do

• Patch and reboot RDMA-enabled NFS/RPC servers to the RHSA-2026:77500 kernel builds first; treat these as the highest-priority kernel update this cycle.
• Until patched, disable svcrdma/rpcrdma and NFS-over-RDMA so the vulnerable pull-up path cannot be reached from the network.
• Inventory hosts with RDMA NICs and nfs-server/nfs-kernel-server roles so no InfiniBand/RoCE/iWARP file server is missed.
• Restrict RDMA/NFS listener exposure to trusted storage fabrics; do not present nfsrdma on general-purpose or internet-facing networks.
• After reboot, verify the running kernel version and that nfsd RDMA listeners match the intended (patched) configuration.
• Watch kernel logs for svcrdma/slab anomalies on unpatched hosts; there is no KEV or known exploit, but the unauthenticated kernel overflow warrants monitoring until all systems are upgraded.