CVE-2026-89533
nicheLinux kernel svcrdma u32 underflow in NFS-over-RDMA Read chunk handling
The Linux kernel's NFS-over-RDMA server code (svcrdma) contains two offset-arithmetic defects in svc_rdma_read_chunk_range(), which rebuilds sub-ranges of Position-Zero and Call Read chunks. A remote attacker who can reach an NFS server configured with the RDMA transport can send a crafted RPC whose Read chunk segment lengths fall on the buggy boundary, causing a u32 length underflow that propagates a near-UINT-MAX value into svc_rdma_build_read_segment() and a multi-MiB kmalloc_array_node() allocation, alongside incorrect DMA lengths that silently drop bytes. Impact is rated critical (CVSS 9.8, network, no authentication) and plausibly includes kernel memory corruption, privilege-equivalent code execution in kernel context, or server crash. Affected systems are Linux NFS servers exposing the RDMA transport (NFSoRDMA over InfiniBand or RoCE fabrics, typically HPC and storage clusters). No public proof of concept is known and the issue is not in the CISA KEV catalog.
What to do: Apply a kernel containing the svcrdma fix (check your distro's kernel advisory for the svc_rdma_read_chunk_range() commit) and reboot affected NFS servers. If RDMA transport for NFS is not required, disable the rdma NFSD transport and ensure NFS-over-RDMA ports (e.g., 20049) are never reachable outside the trusted cluster fabric. Audit HPC/storage clusters running NFS over InfiniBand or RoCE first, as they are the realistic attack surface.
| Linux kernel (svcrdma / NFS-over-RDMA server transport) | — |
Order-of-magnitude estimate by the model from install counts, market share and public scan data it knows; verify before quoting.
In the Linux kernel, the following vulnerability has been resolved: svcrdma: Fix offset arithmetic in read_chunk_range svc_rdma_read_chunk_range() walks a Read chunk's segment list to build a sub-range starting at byte offset and spanning length bytes for a Position-Zero or Call chunk. Two arithmetic defects in the per-segment loop produce wrong DMA lengths and a u32 underflow: pcl_for_each_segment(segment, chunk) { if (offset > segment->rs_length) { offset -= segment->rs_length; continue; } dummy.rs_handle = segment->rs_handle; dummy.rs_length = min_t(u32, length, segment->rs_length) - offset; dummy.rs_offset = segment->rs_offset + offset; First, the skip predicate uses '>' instead of '>='. When offset equals the segment's full rs_length, the segment is fully consumed and should be skipped, but the loop falls through into the body. The resulting dummy.rs_length is min_t(u32, length, rs_length) - rs_length, which underflows to a near-UINT_MAX u32 when length is smaller than rs_length, or is zero otherwise. Second, the length formula subtracts offset from the min_t() result rather than from segment->rs_length before the cap. For offset > 0 the segment's residual is rs_length - offset, not rs_length, so the cap must be applied to the residual. With the current bracketing, whenever length is smaller than rs_length - offset the per-segment length becomes length - offset instead of length, silently dropping offset bytes from the rebuilt chunk. Combined with the boundary case above it also enables the u32 underflow path, which propagates a huge nr_bvec into svc_rdma_build_read_segment() and a multi-MiB kmalloc_array_node() in svc_rdma_get_rw_ctxt(). Additionally, svc_rdma_read_call_chunk() can invoke this function with length == 0 when the last Read chunk ends exactly at the end of the Call chunk. With the corrected >= predicate, every segment is skipped and the function returns the initial -EINVAL, rejecting a valid request. Return success immediately when length is zero. Also break out of the loop once length is fully consumed to avoid passing zero-length segments to svc_rdma_build_read_segment(). Fix by using '>=' so a fully-consumed segment is skipped, by moving '- offset' inside min_t() so the cap is applied to the segment's residual length, by returning success for zero-length requests, and by stopping iteration when the requested range has been consumed.
- Vector
- CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
In the news0 stories
No ingested article mentions this CVE yet.