CVE-2026-64269: RDMA/rtrs-srv: Bound RDMA-Write length to chunk size in rdma_write_sg

Greg Kroah-Hartman <[email protected]> Sat, 25 Jul 2026 10:48:06 +0200
Newsgroups org.kernel.vger.linux-cve-announce
Message-ID <2026072559-CVE-2026-64269-6d9f@gregkh>
From: Greg Kroah-Hartman <[email protected]>

Description
===========

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

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

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

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

rd_msg points into the chunk buffer that the remote peer filled via
RDMA-WRITE-WITH-IMM (rtrs_srv_rdma_done() -> process_io_req() ->
process_read()), so desc[0].len is attacker-controlled and, before this
change, was only rejected when zero. The source address is the fixed
chunk start (dma_addr[msg_id]) and the source lkey is the PD-wide
local_dma_lkey, which is not tied to the chunk's MR mapping, so the verbs
layer does not constrain the transfer length to max_chunk_size. msg_id
and off are bounded against queue_depth and max_chunk_size in
rtrs_srv_rdma_done(), 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 max_chunk_size 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 max_chunk_size, mirroring the existing
off >= max_chunk_size bound in rtrs_srv_rdma_done(). Legitimate clients
do not exceed it: the client sets desc[0].len to its MR length, which is
capped at the negotiated max_io_size (max_chunk_size - MAX_HDR_SIZE).

The Linux kernel CVE team has assigned CVE-2026-64269 to this issue.


Affected and fixed versions
===========================

	Issue introduced in 5.8 with commit 9cb837480424e78ed585376f944088246685aec3 and fixed in 5.15.212 with commit 68c09762172f6224e9ddf9b0a60bacbb36e443eb
	Issue introduced in 5.8 with commit 9cb837480424e78ed585376f944088246685aec3 and fixed in 6.1.178 with commit 6cada540150894e81042a0ae0c796a21a9a877da
	Issue introduced in 5.8 with commit 9cb837480424e78ed585376f944088246685aec3 and fixed in 6.6.145 with commit 2912f3d40355dabc08fdbaaf2764d02445fe88dc
	Issue introduced in 5.8 with commit 9cb837480424e78ed585376f944088246685aec3 and fixed in 6.12.96 with commit 6f40246f4312fdbab5a13cc440adebf95eb2aa66
	Issue introduced in 5.8 with commit 9cb837480424e78ed585376f944088246685aec3 and fixed in 6.18.39 with commit 5a45d0aa1fa50a333ce5763ade744e2d89838667
	Issue introduced in 5.8 with commit 9cb837480424e78ed585376f944088246685aec3 and fixed in 7.1.4 with commit da3e44add94b05dfde56f898421922f5cf35705f
	Issue introduced in 5.8 with commit 9cb837480424e78ed585376f944088246685aec3 and fixed in 7.2-rc1 with commit 963af8d97a8c6a117134a8d0db1415e0489200b1

Please see https://www.kernel.org for a full list of currently supported
kernel versions by the kernel community.

Unaffected versions might change over time as fixes are backported to
older supported kernel versions.  The official CVE entry at
	https://cve.org/CVERecord/?id=CVE-2026-64269
will be updated if fixes are backported, please check that for the most
up to date information about this issue.


Affected files
==============

The file(s) affected by this issue are:
	drivers/infiniband/ulp/rtrs/rtrs-srv.c


Mitigation
==========

The Linux kernel CVE team recommends that you update to the latest
stable kernel version for this, and many other bugfixes.  Individual
changes are never tested alone, but rather are part of a larger kernel
release.  Cherry-picking individual commits is not recommended or
supported by the Linux kernel community at all.  If however, updating to
the latest release is impossible, the individual changes to resolve this
issue can be found at these commits:
	https://git.kernel.org/stable/c/68c09762172f6224e9ddf9b0a60bacbb36e443eb
	https://git.kernel.org/stable/c/6cada540150894e81042a0ae0c796a21a9a877da
	https://git.kernel.org/stable/c/2912f3d40355dabc08fdbaaf2764d02445fe88dc
	https://git.kernel.org/stable/c/6f40246f4312fdbab5a13cc440adebf95eb2aa66
	https://git.kernel.org/stable/c/5a45d0aa1fa50a333ce5763ade744e2d89838667
	https://git.kernel.org/stable/c/da3e44add94b05dfde56f898421922f5cf35705f
	https://git.kernel.org/stable/c/963af8d97a8c6a117134a8d0db1415e0489200b1