CVE-2026-89533

What it actually does

Integer underflow and incorrect DMA-length arithmetic in the Linux kernel NFS-over-RDMA server (svcrdma) when svc_rdma_read_chunk_range() rebuilds a Position-Zero or Call Read-chunk sub-range. A fully consumed segment is not skipped, so dummy.rs_length underflows a u32 toward UINT_MAX; that huge length becomes nr_bvec and drives an oversized kmalloc_array_node() in svc_rdma_get_rw_ctxt() plus wrong DMA mapping in svc_rdma_build_read_segment(), yielding kernel memory corruption, unbounded allocation, and host crash, with a plausible further path to kernel-memory safety violations.

Why it matters to the business

Any host exposing NFS over RDMA can be crashed remotely by an unauthenticated network peer, taking file services and the whole machine offline; memory corruption also implies a risk of kernel-level compromise of the file server. The issue is scored critical (network-reachable, no privileges or user interaction) and has been public for about 34 days, so unpatched NFS/RDMA servers remain a high operational risk even though it is not listed in CISA KEV, is not associated with ransomware, and has no reported in-the-wild exploit maturity.

How an attack unfolds

An unauthenticated attacker who can reach an NFS server with the RDMA transport enabled sends an RPC Call whose Read-chunk segment list and requested offset/length hit the defective skip predicate and residual-length formula. The kernel treats a fully consumed segment as still in-range, underflows the per-segment length, and attempts a multi-mebibyte RDMA work-context allocation and DMA setup. That typically panics or OOM-kills the host; if allocation and mapping succeed with corrupted sizes, kernel heap and DMA state can be corrupted. No named threat actors or public exploit activity are reported.

How to fix it

Install a Linux kernel that includes the svcrdma fix for this issue (corrected >= skip of fully consumed segments, residual length capped with offset inside min_t, immediate success on zero-length ranges, and loop exit once the requested length is consumed). Apply the vendor or distro kernel update that cites this CVE; no per-package fixed version list was supplied with this record, so use the supplier advisory for the exact kernel package. If NFS over RDMA is not required, unload or blacklist svcrdma/xprtrdma/rpcrdma, disable nfsrdma, and stop advertising RDMA NFS. Restrict who can reach NFS/RDMA endpoints with network ACLs or fabric zoning until kernels are patched.

How to confirm the fix worked

Confirm the running kernel changelog, distro errata, or upstream commit contains the svcrdma read_chunk_range arithmetic fix, then reboot into that kernel. Verify svcrdma/rpcrdma module versions and that nfs-utils/rdma configuration matches the patched kernel. After patching, exercise legitimate NFS-over-RDMA I/O (including Call/Read chunks that end on segment boundaries and zero-length trailing ranges) and confirm there are no new oopses, unexpected -EINVAL on valid Calls, or oversized kmalloc warnings. On unpatched hosts, treat loaded svcrdma plus an enabled nfsrdma listener as exposed.

Typical attack path

1. Discover a Linux NFS server with RDMA (svcrdma) enabled and reachable on the RDMA fabric or associated IP/port path.
2. Establish a normal NFS/RDMA session as an unauthenticated or unprivileged network peer.
3. Submit an RPC Call that includes a Position-Zero or Call Read chunk whose segment lengths and byte offset/length combination exercise the off-by-one skip and residual-length bugs.
4. Trigger u32 underflow so the server computes an enormous DMA/bvec count and performs an oversized allocation and mapping.
5. Cause kernel oops, OOM, or memory corruption on the NFS server, resulting in denial of service and, if corruption is controllable, potential kernel-level impact.

How to detect it

There are no public exploit signatures or named actor TTPs. Hunt retrospectively on NFS/RDMA servers for kernel oops, BUG, panic, or OOM around svcrdma allocation and DMA setup, especially large or failed kmalloc_array_node allocations while handling Read chunks. Review dmesg/journal/kern.log and crash dumps for stacks through svc_rdma_read_chunk_range, svc_rdma_read_call_chunk, svc_rdma_build_read_segment, and svc_rdma_get_rw_ctxt. Correlate timestamps with unusual inbound RDMA or NFS/RDMA sessions, connection storms, or client disconnects. A single crash without a matching patch window is more consistent with accidental trigger or probing than confirmed targeted exploitation, given exploit maturity of None.

• svc_rdma_read_chunk_range
• svc_rdma_read_call_chunk
• svc_rdma_build_read_segment
• svc_rdma_get_rw_ctxt
• svcrdma
• kmalloc_array_node
• Call Trace:.*svcrdma
• Oops:.*svcrdma
• Out of memory:.*svcrdma

What your security team should do

• Prioritize kernel updates on all NFS servers with RDMA enabled; treat as urgent given unauthenticated remote reachability even though the CVE is not in KEV.
• Inventory hosts with svcrdma, rpcrdma, or nfsrdma loaded and disable NFS over RDMA where it is not a business requirement.
• Network-restrict RDMA and NFS listener endpoints to known clients until patches are confirmed.
• Watch kernel logs on NFS/RDMA servers for oops, OOM, and oversized allocation in the RDMA server path as a stopgap detection control.
• Track distro kernel advisories for this CVE and verify rollout with configuration management rather than assuming a generic kernel bump is sufficient.