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, svcrdmapullupneeded() selects

pull-up and svcrdmapullupreply_msg() linearizes the whole

reply into sctxt->scxprtbuf. That buffer is only scmaxreq_size

bytes, while the reply on this path is bounded only by the client's

request, so svcrdmaxb_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 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 scmaxreq_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 svcrdmapullupneeded() to

svcrdmacheckpullup() so its name no longer implies a boolean

predicate.