CVE-2026-89530
nicheKernel heap overflow in Linux svcrdma NFS-over-RDMA server reply pull-up
The Linux kernel's svcrdma subsystem (the server side of RPC-over-RDMA, used by nfsd to serve NFS over RDMA) contains a heap buffer overflow in reply handling. An unauthenticated remote client can trigger it by sending a request with no Write list and no Reply chunk — for example an NFS READ — such that the reply needs more scatter/gather entries than the RDMA device's Send Queue supports, forcing svc_rdma_xb_linearize() to copy the entire reply into a pull-up buffer that is only sc_max_req_size bytes, writing past its end and corrupting adjacent slab memory, while the oversized SGE length also makes the device DMA-read beyond the mapped region. Because the reply size on this path is bounded only by the attacker's request, a reachable attacker can corrupt kernel memory with attacker-influenced data, plausibly yielding kernel code execution, information disclosure, or a crash (CVSS 9.8, AV:N/AC:L/PR:N). Any Linux system acting as an NFS server with the RDMA transport enabled is affected; the fix makes the pull-up check return -E2BIG and fail the request with ERR_CHUNK per RFC 8166 rather than overflowing. No public PoC exists and no exploitation has been observed, and the flaw is not in CISA's KEV catalog.
What to do: Patch to a kernel release containing the svcrdma fix (identified by the rename of svc_rdma_pull_up_needed() to svc_rdma_check_pull_up() with -E2BIG handling) as soon as your distro ships it. Until then, disable or firewall the nfsd RDMA listener (do not enable the RDMA transport / block the RDMA service port, typically 20049/tcp) and restrict RDMA fabric access to trusted NFS clients only. Watch NFS/RDMA servers for unexplained slab corruption, OOPSes, or sudden reboots, and confirm post-patch that oversized no-chunk requests are rejected with ERR_CHUNK rather than dropping the connection.
| Linux kernel (svcrdma / NFSD RPC-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: Reject inline replies that overflow the pull-up buffer An RPC-over-RDMA client can request a reply, such as an NFS READ payload, without providing a Write list or a Reply chunk to carry it. When such a reply needs more scatter/gather entries than the device's Send Queue supports, svc_rdma_pull_up_needed() selects pull-up and svc_rdma_pull_up_reply_msg() linearizes the whole reply into sctxt->sc_xprt_buf. That buffer is only sc_max_req_size bytes, while the reply on this path is bounded only by the client's request, so svc_rdma_xb_linearize() copies past the end of the buffer and corrupts adjacent slab memory. The oversized length is then stored in sc_sges[0].length and posted, so the device also reads beyond the mapped region. The SGE-exhaustion branch is the only pull-up path that can exceed the buffer: the threshold branch pulls up only replies smaller than RPCRDMA_PULLUP_THRESH, and replies that fit the device's SGE budget are sent directly without linearization. Make svc_rdma_pull_up_needed() report -E2BIG when the reply it would pull up cannot fit sc_max_req_size, and fail the request with ERR_CHUNK as RFC 8166 Section 4.5.3 directs rather than dropping the connection. The helper no longer answers a simple yes/no question: it now reports pull-up, no pull-up, or -E2BIG for a reply too large to linearize. Rename svc_rdma_pull_up_needed() to svc_rdma_check_pull_up() so its name no longer implies a boolean predicate.
- 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.