<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" version="2.0">
  <channel>
    <title>Most recent entries from all</title>
    <link>https://vulnerability.circl.lu</link>
    <description>Contains only the most 10 recent entries.</description>
    <docs>http://www.rssboard.org/rss-specification</docs>
    <generator>python-feedgen</generator>
    <language>en</language>
    <lastBuildDate>Tue, 29 Sep 2026 17:18:59 +0000</lastBuildDate>
    <item>
      <title>CVE-2026-64268 — RDMA/siw: bound Read Response placement to the RREAD length</title>
      <link>https://vulnerability.circl.lu/vuln/cve-2026-64268</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Linux&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;RDMA/siw: bound Read Response placement to the RREAD length&lt;/p&gt;
&lt;p&gt;In drivers/infiniband/sw/siw/siw_qp_rx.c, siw_proc_rresp() places each
inbound Read Response DDP segment at sge-&amp;gt;laddr + wqe-&amp;gt;processed and then
accumulates wqe-&amp;gt;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-&amp;gt;bytes only on the final segment (the !frx-&amp;gt;more_ddp_segs guard).&lt;/p&gt;
&lt;p&gt;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-&amp;gt;processed past the validated sink
buffer; the next siw_rx_data() call writes out of bounds at
sge-&amp;gt;laddr + wqe-&amp;gt;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.&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;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 de…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Linux&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;RDMA/siw: bound Read Response placement to the RREAD length&lt;/p&gt;
&lt;p&gt;In drivers/infiniband/sw/siw/siw_qp_rx.c, siw_proc_rresp() places each
inbound Read Response DDP segment at sge-&amp;gt;laddr + wqe-&amp;gt;processed and then
accumulates wqe-&amp;gt;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-&amp;gt;bytes only on the final segment (the !frx-&amp;gt;more_ddp_segs guard).&lt;/p&gt;
&lt;p&gt;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-&amp;gt;processed past the validated sink
buffer; the next siw_rx_data() call writes out of bounds at
sge-&amp;gt;laddr + wqe-&amp;gt;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.&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;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 de…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/cve-2026-64268</guid>
    </item>
  </channel>
</rss>
