Skip to main content
VulnerabilityPublished

CVE-2026-64268: Linux kernel · RDMA/siw: bound Read Response placement to the RREAD length

Source GCVE Database

0
Authoritative record:CVE-2026-64268· Critical 9.8

Not known to be exploited · CVSS 9.8 Critical · fixed in b2e26c955f8dd7e8d3f16c858db05245ea4fa817 : patch Linux kernel as a priority.

Data as of 26 Oct 2026, 14:05 UTC

CVSS 3.1 base score
9.8Critical
How severe the flaw is on the 0–10 CVSS scale.
EPSS
0.7% chance of exploitation in 30 days – higher than 53% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
Patch
Available – fixed in b2e26c955f8dd7e8d3f16c858db05245ea4fa817, a31b6d18ded3cc32d9ee85a6ff0726d4274887b2, 595e6537ad1a210da32cbb9a7f91aa73090915ba +5
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

Exploitation evidence

  1. Disclosed: evidence found.

    CVE published 25 Jul 2026

  2. Detectable: no evidence on record.

    No public nuclei template indexed

  3. Weaponised: no evidence on record.

    No public exploit code indexed in Metasploit or Exploit-DB

  4. Exploited in the wild: no evidence on record.

    Not in CISA KEV and no source reports exploitation

  5. Observed by OffSeq Mirage: no evidence on record.

    No attack traffic recorded by OffSeq Mirage sensors

A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 26 Oct 2026.

What to do

Upgrade to a fixed release listed under Affected software.

Affected software

ProductAffectedFixed in
LinuxLinuxAffected
  • ≥ 8b6a361b8c482f22ac99c3273285ff16b23fba91, < b2e26c955f8dd7e8d3f16c858db05245ea4fa817
Fixed in
  • b2e26c955f8dd7e8d3f16c858db05245ea4fa817
LinuxLinuxAffected
  • ≥ 8b6a361b8c482f22ac99c3273285ff16b23fba91, < a31b6d18ded3cc32d9ee85a6ff0726d4274887b2
Fixed in
  • a31b6d18ded3cc32d9ee85a6ff0726d4274887b2
LinuxLinuxAffected
  • ≥ 8b6a361b8c482f22ac99c3273285ff16b23fba91, < 595e6537ad1a210da32cbb9a7f91aa73090915ba
Fixed in
  • 595e6537ad1a210da32cbb9a7f91aa73090915ba
LinuxLinuxAffected
  • ≥ 8b6a361b8c482f22ac99c3273285ff16b23fba91, < 423a78ff7928c2601013f73ec6d896f5597d0df5
Fixed in
  • 423a78ff7928c2601013f73ec6d896f5597d0df5
LinuxLinuxAffected
  • ≥ 8b6a361b8c482f22ac99c3273285ff16b23fba91, < 75c93cd3c421890f49ea93f0b978b9b7bb10e5e3
Fixed in
  • 75c93cd3c421890f49ea93f0b978b9b7bb10e5e3
LinuxLinuxAffected
  • ≥ 8b6a361b8c482f22ac99c3273285ff16b23fba91, < 7d29f7e9dbd844cae4d3e559cf78324b9642fd6b
Fixed in
  • 7d29f7e9dbd844cae4d3e559cf78324b9642fd6b

AI-suggested

A fix is available that bounds each Read Response segment before placement and terminates connections that would cause buffer overruns. Users should apply the official Linux kernel patches that address this vulnerability.

Description

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

References

Community reviews

Loading reviews…