Skip to content

CVE-2026-64269

Linux Kernel vulnerability

9.1 CRITICALEPSS 0.71%
  1. Published25 Jul 2026

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

CVSS 3.1 breakdown

Attack vectorNetwork
Attack complexityLow
Privileges requiredNone
User interactionNone
ScopeUnchanged
ConfidentialityHigh
IntegrityNone
AvailabilityHigh
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:H

Affected products

Linux Kernel≥ 5.16 < 6.1.178 · ≥ 5.8 < 5.15.212 · ≥ 6.13 < 6.18.39 · ≥ 6.19 < 7.1.4

Frequently asked

Is CVE-2026-64269 being actively exploited?

CVE-2026-64269 is not in the CISA KEV catalog. Its EPSS exploit probability is 0.71%.

How severe is CVE-2026-64269?

CVE-2026-64269 has a CVSS 3.1 base score of 9.1, rated critical. EPSS estimates a 0.71% probability of exploitation.

Which products are affected by CVE-2026-64269?

Affected products include Linux Kernel.

How do I fix CVE-2026-64269?

Upgrade affected software to a fixed version, for example Linux Kernel 6.1.178 or later, then confirm no affected versions remain in your inventory.

How Secuno handles this

Secuno correlates vulnerabilities like CVE-2026-64269 against the real software inventory on every managed device, every day. Rather than a static severity, each match is scored in context: exploit availability, EPSS, the asset's exposure, and business criticality decide where it lands in the queue. If an affected version is present anywhere across your portfolio, it surfaces automatically with a prioritised remediation path.

Get Patch this first every Monday

Five vulnerabilities that matter this week, ranked on real exploitation. Plain language, one email, no spam.

You can unsubscribe with one click from every issue. We handle your details as described in our privacy policy.

Data from the NVD, CISA KEV catalog and FIRST EPSS. CVSS 3.1 base score shown where available.