{ "schema_version": "1.6.1", "id": "RPI-CVE-2026-64269", "modified": "2026-10-09T11:39:44Z", "upstream": [ "CVE-2026-64269" ], "published": "2026-07-25T08:51:45Z", "summary": "RDMA/rtrs-srv: Bound RDMA-Write length to chunk size in rdma_write_sg", "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/rtrs-srv: Bound RDMA-Write length to chunk size in rdma_write_sg\n\nWhen the server answers an RTRS READ, rdma_write_sg() builds the source\nscatter/gather entry for the IB_WR_RDMA_WRITE that returns data to the\npeer. Its length is taken directly from the wire descriptor:\n\n plist->length = le32_to_cpu(id->rd_msg->desc[0].len);\n\nrd_msg points into the chunk buffer that the remote peer filled via\nRDMA-WRITE-WITH-IMM (rtrs_srv_rdma_done() -> process_io_req() ->\nprocess_read()), so desc[0].len is attacker-controlled and, before this\nchange, was only rejected when zero. The source address is the fixed\nchunk start (dma_addr[msg_id]) and the source lkey is the PD-wide\nlocal_dma_lkey, which is not tied to the chunk's MR mapping, so the verbs\nlayer does not constrain the transfer length to max_chunk_size. msg_id\nand off are bounded against queue_depth and max_chunk_size in\nrtrs_srv_rdma_done(), but desc[0].len is a separate field that was not\nchecked against the chunk size.\n\nA peer that advertises desc[0].len larger than max_chunk_size can make\nthe posted RDMA write read past the chunk's mapped region. The resulting\nbehaviour depends on the IOMMU configuration: with no IOMMU or in\npassthrough mode the read may extend into memory adjacent to the chunk\nand be returned to the peer, which can disclose host memory; with a\ntranslating IOMMU the out-of-range access is expected to fault and abort\nthe connection. In either case the transfer exceeds what the protocol\npermits and is driven by a remote peer.\n\nReject a descriptor length above max_chunk_size, mirroring the existing\noff >= max_chunk_size bound in rtrs_srv_rdma_done(). Legitimate clients\ndo not exceed it: the client sets desc[0].len to its MR length, which is\ncapped at the negotiated max_io_size (max_chunk_size - MAX_HDR_SIZE).", "severity": [ { "type": "CVSS_V3", "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:H" } ], "affected": [ { "package": { "ecosystem": "Raspberry Pi OS:12", "name": "linux" }, "versions": [ "1:6.1.47-1+rpt4" ], "ecosystem_specific": { "binaries": [ { "binary_name": "linux-image-6.1.0-rpi3-rpi-2712", "binary_version": "1:6.1.47-1+rpt4" }, { "binary_name": "linux-image-6.1.0-rpi3-rpi-v6", "binary_version": "1:6.1.47-1+rpt4" }, { "binary_name": "linux-image-6.1.0-rpi3-rpi-v7", "binary_version": "1:6.1.47-1+rpt4" }, { "binary_name": "linux-image-6.1.0-rpi3-rpi-v7l", "binary_version": "1:6.1.47-1+rpt4" }, { "binary_name": "linux-image-6.1.0-rpi3-rpi-v8", "binary_version": "1:6.1.47-1+rpt4" } ] }, "database_specific": { "per_version": { "1:6.1.47-1+rpt4": { "linux_commit": "655fc658a15ae7a6f37103754adb39ba52a9a14e", "upstream_version": "6.1.47", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.1.178", "compiled_filter": false } } } } ], "references": [ { "type": "ADVISORY", "url": "https://www.cve.org/CVERecord?id=CVE-2026-64269" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/a35b7a8728a53ddc80b323970689fa5985816836" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/68c09762172f6224e9ddf9b0a60bacbb36e443eb" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/6cada540150894e81042a0ae0c796a21a9a877da" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/2912f3d40355dabc08fdbaaf2764d02445fe88dc" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/6f40246f4312fdbab5a13cc440adebf95eb2aa66" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/5a45d0aa1fa50a333ce5763ade744e2d89838667" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/da3e44add94b05dfde56f898421922f5cf35705f" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/963af8d97a8c6a117134a8d0db1415e0489200b1" } ], "database_specific": { "source": "https://git.kernel.org/pub/scm/linux/security/vulns.git", "upstream_modified": "2026-08-23T12:46:35Z", "severity": { "source": "kernel CNA", "cvss_v3_score": 9.1, "cvss_v3_severity": "Critical", "scenario": "AV:N - RTRS accepts network connections over routable RDMA transports including RoCE and iWARP, and the malicious descriptor is supplied by a remote peer.\nAC:L - The peer directly controls the descriptor length and destination buffer; no race, timing, or victim-controlled state is required in no-IOMMU, passthrough, or software-RDMA deployments.\nPR:N - The handshake validates protocol fields but performs no credential, capability, or authentication check before publishing chunk rkeys and accepting I/O requests.\nUI:N - After connecting, the attacker can submit the crafted RDMA READ request without any victim action.\nS:U - The vulnerable RTRS module and affected host memory remain within the kernel's security authority; a translating IOMMU prevents rather than permits crossing its isolation boundary.\nC:H - The PD-wide local DMA key does not constrain the attacker-supplied transfer length, permitting a broad out-of-bounds read of adjacent host memory that is returned to the peer.\nI:N - The malformed operation reads server memory and writes it only to the peer's registered destination; it provides no server-side memory-write primitive.\nA:H - Software-RDMA can CPU-copy through invalid pages and oops or crash, while hardware or IOMMU faults can abort paths. An unauthenticated peer can trigger the condition repeatedly." } } }