CVE-2026-89530: svcrdma: Reject inline replies that overflow the pull-up buffer
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, svcrdmapullupneeded() selects pull-up and svcrdmapullupreplymsg() linearizes the whole reply into sctxt->scxprtbuf. That buffer is only scmaxreqsize bytes, while the reply on this path is bounded only by the client's request, so svcrdmaxblinearize() copies past the end of the buffer and corrupts adjacent slab memory. The oversized length is then stored in scsges[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 RPCRDMAPULLUPTHRESH, and replies that fit the device's SGE budget are sent directly without linearization. Make svcrdmapullupneeded() report -E2BIG when the reply it would pull up cannot fit scmaxreqsize, and fail the request with ERRCHUNK 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 svcrdmapullupneeded() to svcrdmacheckpullup() so its name no longer implies a boolean predicate.
Affected Software
Event History
Frequently Asked Questions
Which systems are exposed to this issue?
Systems acting as RPC-over-RDMA servers are exposed when a client can issue requests that produce replies without a Write list or Reply chunk. NFS READ replies are identified as one example.
What must an attacker do to trigger the vulnerable path?
The attacker needs to send an RPC-over-RDMA request that causes a reply too large for the device Send Queue's scatter/gather-entry budget, while omitting both a Write list and Reply chunk. This forces reply pull-up and can cause the reply to exceed the transport buffer size.
How can the vulnerable condition be recognized?
The condition occurs specifically when SGE exhaustion selects the pull-up path and the reply is larger than sc_max_req_size. In the affected behavior, the reply is linearized into sc_xprt_buf despite exceeding that buffer, and an oversized length is posted in sc_sges[0].length.
What does the fix do when an oversized reply would need pull-up?
The fix makes svc_rdma_pull_up_needed() return -E2BIG if the reply cannot fit in sc_max_req_size. The request is then failed with ERR_CHUNK instead of linearizing the oversized reply.