CVE-2026-64269

In the Linux kernel, the following vulnerability has been resolved:

RDMA/rtrs-srv: Bound RDMA-Write length to chunk size in rdmawritesg

When the server answers an RTRS READ, rdmawritesg() builds the source scatter/gather entry for the IBWRRDMA_WRITE that returns data to the peer. Its length is taken directly from the wire descriptor:

plist->length = le32tocpu(id->rd_msg->desc[0].len);

rdmsg points into the chunk buffer that the remote peer filled via RDMA-WRITE-WITH-IMM (rtrssrvrdmadone() -> processioreq() -> processread()), so desc[0].len is attacker-controlled and, before this change, was only rejected when zero. The source address is the fixed chunk start (dmaaddr[msgid]) and the source lkey is the PD-wide localdmalkey, which is not tied to the chunk's MR mapping, so the verbs layer does not constrain the transfer length to maxchunksize. msgid and off are bounded against queuedepth and maxchunksize in rtrssrvrdmadone(), but desc[0].len is a separate field that was not checked against the chunk size.

A peer that advertises desc[0].len larger than maxchunksize can make the posted RDMA write read past the chunk's mapped region. The resulting behaviour depends on the IOMMU configuration: with no IOMMU or in passthrough mode the read may extend into memory adjacent to the chunk and be returned to the peer, which can disclose host memory; with a translating IOMMU the out-of-range access is expected to fault and abort the connection. In either case the transfer exceeds what the protocol permits and is driven by a remote peer.

Reject a descriptor length above maxchunksize, mirroring the existing off >= maxchunksize bound in rtrssrvrdmadone(). Legitimate clients do not exceed it: the client sets desc[0].len to its MR length, which is capped at the negotiated maxiosize (maxchunksize - MAXHDR_SIZE).