CVE-2026-64269

What it is

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).

At a glance

Exploitability

Can be exploited over the network without logging in. High risk of data exposure, service disruption.

Exploit odds

0.7% chance of exploitation in the next 30 days (EPSS).

Fix

A patch, advisory or fixed version is referenced. Upgrade or apply it.

Timeline

1. 2026-07-25 10:17 UTC PublishedDisclosed publicly on CVE.org and NVD
2. 2026-08-23 13:16 UTC Last updatedMost recent change to the record

Why it ranks here

• Exploited in the wild: no, CISA does not list it.
• Exploit odds: 0.7% in the next 30 days (EPSS).
• Severity: 9.1 CRITICAL (CVSS).
• Fix: a patch or advisory is linked.

Details

Published

2026-07-25 10:17 UTC

Last modified

2026-08-23 13:16 UTC

Exploit probability

0.7% · EPSS, next 30 days

Record status

Modified

Affected

• Linux Kernel < 5.15.212
• Linux Kernel < 6.1.178
• Linux Kernel < 6.6.145
• Linux Kernel < 6.12.96
• Linux Kernel < 6.18.39
• Linux Kernel < 7.1.4

Attack profile CVSS 3.1 · 9.1

Attack vector

Network

Complexity

Low

Privileges needed

None

User interaction

None

Scope

Unchanged

Confidentiality

High

Integrity

None

Availability

High

Is it in your code?

Hand this to your coding agent. It searches your project for the affected products and checks versions. Nothing leaves your machine.

Read https://cve-list.com/agent/cve/CVE-2026-64269.md and follow it. Check whether this project is affected by CVE-2026-64269. Read only. Don't change anything and don't upload my code. Tell me yes, no or not sure, with the file as proof.

Copy as ticket · More options · Status badge