<?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://db.gcve.eu</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>Thu, 29 Oct 2026 15:33:53 +0000</lastBuildDate>
    <item>
      <title>CVE-2026-99166 — net: rds: fix uninitialized trans dereference in CM event handler</title>
      <link>https://db.gcve.eu/vuln/cve-2026-99166</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;net: rds: fix uninitialized trans dereference in CM event handler&lt;/p&gt;
&lt;p&gt;rds_rdma_cm_event_handler_cmn() assigns trans only when the RDMA
device is an InfiniBand CA (RDMA_NODE_IB_CA).  On any other device
type, e.g. an iWARP RNIC such as siw, trans stays uninitialized, but
the event switch dereferences it: unconditionally in the
RDMA_CM_EVENT_CONNECT_REQUEST case via trans-&amp;gt;cm_handle_connect(),
and (with a connection context) in the ROUTE_RESOLVED and
ESTABLISHED cases.&lt;/p&gt;
&lt;p&gt;An RDS listener on an iWARP device therefore crashes the kernel as
soon as a connect request arrives: with CONFIG_INIT_STACK_ALL_ZERO
the wild load becomes a NULL dereference at offset 0xa0
(&amp;amp;trans-&amp;gt;cm_handle_connect) in the iw_cm_wq workqueue.&lt;/p&gt;
&lt;p&gt;GCC masks the bug in default builds by folding the uninitialized
load into &amp;amp;rds_ib_transport; Clang-built kernels take the real
uninitialized path and oops.&lt;/p&gt;
&lt;p&gt;The active side can land on a non-IB device too: the id that
rds_ib_conn_path_connect() creates is not restricted to a node type,
so rdma_resolve_addr() binds it to whichever device serves the local
address, and an iWARP RNIC on the same netdev qualifies.  The crash
there is different: resolving a route on an iWARP id never fills in
cm_id-&amp;gt;route.path_rec, and the ROUTE_RESOLVED case writes
path_rec[0].sl before it calls into the transport.&lt;/p&gt;
&lt;p&gt;The iWARP transport was dropped long ago and IB is the only
transport left, so make that explicit: initialize t…&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;net: rds: fix uninitialized trans dereference in CM event handler&lt;/p&gt;
&lt;p&gt;rds_rdma_cm_event_handler_cmn() assigns trans only when the RDMA
device is an InfiniBand CA (RDMA_NODE_IB_CA).  On any other device
type, e.g. an iWARP RNIC such as siw, trans stays uninitialized, but
the event switch dereferences it: unconditionally in the
RDMA_CM_EVENT_CONNECT_REQUEST case via trans-&amp;gt;cm_handle_connect(),
and (with a connection context) in the ROUTE_RESOLVED and
ESTABLISHED cases.&lt;/p&gt;
&lt;p&gt;An RDS listener on an iWARP device therefore crashes the kernel as
soon as a connect request arrives: with CONFIG_INIT_STACK_ALL_ZERO
the wild load becomes a NULL dereference at offset 0xa0
(&amp;amp;trans-&amp;gt;cm_handle_connect) in the iw_cm_wq workqueue.&lt;/p&gt;
&lt;p&gt;GCC masks the bug in default builds by folding the uninitialized
load into &amp;amp;rds_ib_transport; Clang-built kernels take the real
uninitialized path and oops.&lt;/p&gt;
&lt;p&gt;The active side can land on a non-IB device too: the id that
rds_ib_conn_path_connect() creates is not restricted to a node type,
so rdma_resolve_addr() binds it to whichever device serves the local
address, and an iWARP RNIC on the same netdev qualifies.  The crash
there is different: resolving a route on an iWARP id never fills in
cm_id-&amp;gt;route.path_rec, and the ROUTE_RESOLVED case writes
path_rec[0].sl before it calls into the transport.&lt;/p&gt;
&lt;p&gt;The iWARP transport was dropped long ago and IB is the only
transport left, so make that explicit: initialize t…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/cve-2026-99166</guid>
    </item>
  </channel>
</rss>
