GHSA-86RP-M36J-7R28
Vulnerability from github – Published: 2026-07-25 12:31 – Updated: 2026-07-27 06:30In the Linux kernel, the following vulnerability has been resolved:
RDMA/siw: bound Read Response placement to the RREAD length
In drivers/infiniband/sw/siw/siw_qp_rx.c, siw_proc_rresp() places each inbound Read Response DDP segment at sge->laddr + wqe->processed and then accumulates wqe->processed, but it never checks the running total against the sink buffer length on continuation segments. siw_check_sge() resolves and validates the sink memory only on the first fragment (the if (!*mem) branch), and siw_rresp_check_ntoh() compares the cumulative length against wqe->bytes only on the final segment (the !frx->more_ddp_segs guard).
A connected siw peer that answers an outstanding RREAD with Read Response segments that keep the DDP Last flag clear, carrying more total payload than the RREAD requested, drives wqe->processed past the validated sink buffer; the next siw_rx_data() call writes out of bounds at sge->laddr + wqe->processed. siw runs iWARP over ordinary routable TCP, so the peer is the remote end of an established RDMA connection and needs no local privilege.
Bound every segment before placement, exactly as siw_proc_send() and siw_proc_write() already do for their tagged and untagged paths, and terminate the connection with a base-or-bounds DDP error when the Read Response would overrun the sink buffer.
This is the second receive-path length fix for this file. A separate change rejects an MPA FPDU length that underflows the per-fragment remainder in the header decode; that guard does not cover this case, because here each individual segment length is self-consistent and only the accumulated placement offset overruns the buffer.
{
"affected": [],
"aliases": [
"CVE-2026-64268"
],
"database_specific": {
"cwe_ids": [],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-25T10:17:07Z",
"severity": "CRITICAL"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/siw: bound Read Response placement to the RREAD length\n\nIn drivers/infiniband/sw/siw/siw_qp_rx.c, siw_proc_rresp() places each\ninbound Read Response DDP segment at sge-\u003eladdr + wqe-\u003eprocessed and then\naccumulates wqe-\u003eprocessed, but it never checks the running total against\nthe sink buffer length on continuation segments. siw_check_sge() resolves\nand validates the sink memory only on the first fragment (the if (!*mem)\nbranch), and siw_rresp_check_ntoh() compares the cumulative length against\nwqe-\u003ebytes only on the final segment (the !frx-\u003emore_ddp_segs guard).\n\nA connected siw peer that answers an outstanding RREAD with Read Response\nsegments that keep the DDP Last flag clear, carrying more total payload\nthan the RREAD requested, drives wqe-\u003eprocessed past the validated sink\nbuffer; the next siw_rx_data() call writes out of bounds at\nsge-\u003eladdr + wqe-\u003eprocessed. siw runs iWARP over ordinary routable TCP,\nso the peer is the remote end of an established RDMA connection and needs\nno local privilege.\n\nBound every segment before placement, exactly as siw_proc_send() and\nsiw_proc_write() already do for their tagged and untagged paths, and\nterminate the connection with a base-or-bounds DDP error when the\nRead Response would overrun the sink buffer.\n\nThis is the second receive-path length fix for this file. A separate\nchange rejects an MPA FPDU length that underflows the per-fragment\nremainder in the header decode; that guard does not cover this case,\nbecause here each individual segment length is self-consistent and only\nthe accumulated placement offset overruns the buffer.",
"id": "GHSA-86rp-m36j-7r28",
"modified": "2026-07-27T06:30:31Z",
"published": "2026-07-25T12:31:28Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64268"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3ef7e052cbd05a8b13a51a07b185a39ec93ee1cf"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/423a78ff7928c2601013f73ec6d896f5597d0df5"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/595e6537ad1a210da32cbb9a7f91aa73090915ba"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6bc89f34a4597f9f6d41f7a60c67a3153bfe8851"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/75c93cd3c421890f49ea93f0b978b9b7bb10e5e3"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7d29f7e9dbd844cae4d3e559cf78324b9642fd6b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a31b6d18ded3cc32d9ee85a6ff0726d4274887b2"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b2e26c955f8dd7e8d3f16c858db05245ea4fa817"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.