Skip to content
Heist/ feed
Back to feed
CriticalFix available

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

Type: advisorySources: OSV

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 t

Products
Kernel
Affected versions
Not specified
Fixed versions
5.10.266, 5.15.212, 6.1.178, 6.12.96, 6.18.39, 6.6.145, 7.1.4
CVEs
CVE-2026-64269
Confirmed fixed CVEs
Not specified
Updated in this feed
4 Nov 2026, 04:25 UTC · Revision 1

Source evidence

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

core-osv · Original source

Published 25 Jul 2026, 08:49 UTC

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 t

osv:CVE-2026-64269

Kernel

Fixed versions: 5.10.266, 5.15.212, 6.1.178, 6.6.145, 6.12.96, 6.18.39, 7.1.4

Complete source record
{
  "id": "17b51cc09baf29fe39fd670c6cbcc483ef7d3a02c2f2c2b4dc2e839c983dadd4",
  "url": "https://osv.dev/vulnerability/CVE-2026-64269",
  "method": "structured",
  "payload": {
    "kind": "advisory",
    "title": "RDMA/rtrs-srv: Bound RDMA-Write length to chunk size in rdma_write_sg",
    "summary": "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 t",
    "evidence": "osv:CVE-2026-64269",
    "products": [
      {
        "name": {
          "value": "Kernel",
          "evidence": "/affected/1/package/name"
        },
        "prerequisites": [],
        "fixed_versions": [
          {
            "value": "5.10.266",
            "evidence": "/affected/1/ranges"
          },
          {
            "value": "5.15.212",
            "evidence": "/affected/1/ranges"
          },
          {
            "value": "6.1.178",
            "evidence": "/affected/1/ranges"
          },
          {
            "value": "6.6.145",
            "evidence": "/affected/1/ranges"
          },
          {
            "value": "6.12.96",
            "evidence": "/affected/1/ranges"
          },
          {
            "value": "6.18.39",
            "evidence": "/affected/1/ranges"
          },
          {
            "value": "7.1.4",
            "evidence": "/affected/1/ranges"
          }
        ],
        "affected_versions": []
      }
    ],
    "severity": "critical",
    "structured": {
      "id": "CVE-2026-64269",
      "aliases": [
        "CVE-2026-64269"
      ],
      "metrics": [
        {
          "type": "CVSS_V3",
          "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:H"
        }
      ],
      "affected": [
        {
          "ranges": [
            {
              "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
              "type": "GIT",
              "events": [
                {
                  "introduced": "9cb837480424e78ed585376f944088246685aec3"
                },
                {
                  "fixed": "a35b7a8728a53ddc80b323970689fa5985816836"
                },
                {
                  "fixed": "68c09762172f6224e9ddf9b0a60bacbb36e443eb"
                },
                {
                  "fixed": "6cada540150894e81042a0ae0c796a21a9a877da"
                },
                {
                  "fixed": "2912f3d40355dabc08fdbaaf2764d02445fe88dc"
                },
                {
                  "fixed": "6f40246f4312fdbab5a13cc440adebf95eb2aa66"
                },
                {
                  "fixed": "5a45d0aa1fa50a333ce5763ade744e2d89838667"
                },
                {
                  "fixed": "da3e44add94b05dfde56f898421922f5cf35705f"
                },
                {
                  "fixed": "963af8d97a8c6a117134a8d0db1415e0489200b1"
                }
              ]
            }
          ],
          "database_specific": {
            "source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-64269.json"
          }
        },
        {
          "ranges": [
            {
              "type": "ECOSYSTEM",
              "events": [
                {
                  "introduced": "5.8.0"
                },
                {
                  "fixed": "5.10.266"
                }
              ]
            },
            {
              "type": "ECOSYSTEM",
              "events": [
                {
                  "introduced": "5.11.0"
                },
                {
                  "fixed": "5.15.212"
                }
              ]
            },
            {
              "type": "ECOSYSTEM",
              "events": [
                {
                  "introduced": "5.16.0"
                },
                {
                  "fixed": "6.1.178"
                }
              ]
            },
            {
              "type": "ECOSYSTEM",
              "events": [
                {
                  "introduced": "6.2.0"
                },
                {
                  "fixed": "6.6.145"
                }
              ]
            },
            {
              "type": "ECOSYSTEM",
              "events": [
                {
                  "introduced": "6.7.0"
                },
                {
                  "fixed": "6.12.96"
                }
              ]
            },
            {
              "type": "ECOSYSTEM",
              "events": [
                {
                  "introduced": "6.13.0"
                },
                {
                  "fixed": "6.18.39"
                }
              ]
            },
            {
              "type": "ECOSYSTEM",
              "events": [
                {
                  "introduced": "6.19.0"
                },
                {
                  "fixed": "7.1.4"
                }
              ]
            }
          ],
          "package": {
            "name": "Kernel",
            "ecosystem": "Linux"
          },
          "database_specific": {
            "source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-64269.json"
          }
        }
      ],
      "modified": "2026-10-28T02:30:33.129294181Z",
      "provider": "osv",
      "references": [
        "https://git.kernel.org/stable/c/2912f3d40355dabc08fdbaaf2764d02445fe88dc",
        "https://git.kernel.org/stable/c/5a45d0aa1fa50a333ce5763ade744e2d89838667",
        "https://git.kernel.org/stable/c/68c09762172f6224e9ddf9b0a60bacbb36e443eb",
        "https://git.kernel.org/stable/c/6cada540150894e81042a0ae0c796a21a9a877da",
        "https://git.kernel.org/stable/c/6f40246f4312fdbab5a13cc440adebf95eb2aa66",
        "https://git.kernel.org/stable/c/963af8d97a8c6a117134a8d0db1415e0489200b1",
        "https://git.kernel.org/stable/c/a35b7a8728a53ddc80b323970689fa5985816836",
        "https://git.kernel.org/stable/c/da3e44add94b05dfde56f898421922f5cf35705f",
        "https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/64xxx/CVE-2026-64269.json",
        "https://nvd.nist.gov/vuln/detail/CVE-2026-64269",
        "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git"
      ],
      "provider_metadata": {
        "cna_assigner": "Linux",
        "osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/64xxx/CVE-2026-64269.json"
      }
    },
    "related_cves": [
      {
        "value": "CVE-2026-64269",
        "evidence": "/id"
      }
    ],
    "security_relevant": true,
    "severity_evidence": "/severity/0/score"
  },
  "source_id": "core-osv",
  "document_id": 500288,
  "published_at": "2026-07-25T08:49:16.946+00:00"
}