CVE-2026-89530

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.