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
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
debian/linuxto a version that resolves this vulnerability.Fixed in 6.12.111-1 - Upgrade
Upgrade
debian/linuxto a version that resolves this vulnerability.Fixed in 7.2.6-1 - Upgrade
Upgrade
debian/linux-6.12to a version that resolves this vulnerability.Fixed in 6.12.111-1~deb12u1 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.1.191 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.6.160 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.12.109 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.18.50 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 7.2.4 - Upgrade
Upgrade
debian/linuxto a version that resolves this vulnerability.Fixed in 6.12.115-2Fixed in 7.2.12-1Fixed in 7.2.15-1 - Upgrade
Upgrade
debian/linux-6.12to a version that resolves this vulnerability.Fixed in 6.12.113-1~deb12u1 - Upgrade
Upgrade
ubuntu/linux-hwe-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-42.42~24.04.1 - Upgrade
Upgrade
ubuntu/linux-riscv-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-42.42.1~24.04.1 - Upgrade
Upgrade
ubuntu/linuxto a version that resolves this vulnerability.Fixed in 7.0.0-42.42 - Upgrade
Upgrade
ubuntu/linux-awsto a version that resolves this vulnerability.Fixed in 7.0.0-1016.17 - Upgrade
Upgrade
ubuntu/linux-gcpto a version that resolves this vulnerability.Fixed in 7.0.0-1016.18 - Upgrade
Upgrade
ubuntu/linux-ibmto a version that resolves this vulnerability.Fixed in 7.0.0-1017.17 - Upgrade
Upgrade
ubuntu/linux-oem-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1017.17 - Upgrade
Upgrade
ubuntu/linux-oracleto a version that resolves this vulnerability.Fixed in 7.0.0-1015.16 - Upgrade
Upgrade
ubuntu/linux-riscvto a version that resolves this vulnerability.Fixed in 7.0.0-42.42.1 - Compensating control
Reject inline RPC-over-RDMA replies that cannot fit sc_max_req_size: have svc_rdma_check_pull_up() report -E2BIG and fail the request with ERR_CHUNK as directed by RFC 8166 Section 4.5.3, rather than linearizing past the pull-up buffer or dropping the connection.
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.