CVE-2026-99166

Severity CVSS v4.0:
Pending analysis
Type:
Unavailable / Other
Publication date:
28/10/2026
Last modified:
28/10/2026

Description

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: rds: fix uninitialized trans dereference in CM event handler<br /> <br /> rds_rdma_cm_event_handler_cmn() assigns trans only when the RDMA<br /> device is an InfiniBand CA (RDMA_NODE_IB_CA). On any other device<br /> type, e.g. an iWARP RNIC such as siw, trans stays uninitialized, but<br /> the event switch dereferences it: unconditionally in the<br /> RDMA_CM_EVENT_CONNECT_REQUEST case via trans-&gt;cm_handle_connect(),<br /> and (with a connection context) in the ROUTE_RESOLVED and<br /> ESTABLISHED cases.<br /> <br /> An RDS listener on an iWARP device therefore crashes the kernel as<br /> soon as a connect request arrives: with CONFIG_INIT_STACK_ALL_ZERO<br /> the wild load becomes a NULL dereference at offset 0xa0<br /> (&amp;trans-&gt;cm_handle_connect) in the iw_cm_wq workqueue.<br /> <br /> GCC masks the bug in default builds by folding the uninitialized<br /> load into &amp;rds_ib_transport; Clang-built kernels take the real<br /> uninitialized path and oops.<br /> <br /> The active side can land on a non-IB device too: the id that<br /> rds_ib_conn_path_connect() creates is not restricted to a node type,<br /> so rdma_resolve_addr() binds it to whichever device serves the local<br /> address, and an iWARP RNIC on the same netdev qualifies. The crash<br /> there is different: resolving a route on an iWARP id never fills in<br /> cm_id-&gt;route.path_rec, and the ROUTE_RESOLVED case writes<br /> path_rec[0].sl before it calls into the transport.<br /> <br /> The iWARP transport was dropped long ago and IB is the only<br /> transport left, so make that explicit: initialize trans to<br /> &amp;rds_ib_transport at declaration, drop the conditional assignment,<br /> reject a connect request that arrives on a non-IB device, and drop a<br /> connection whose address resolved to one instead of resolving a<br /> route on it. The rejection is limited to RDMA_CM_EVENT_CONNECT_REQUEST<br /> on purpose: a non-zero return from the handler makes rdma_cm destroy<br /> the id the event was delivered on, which is right for the request&amp;#39;s<br /> freshly created id but would free a connection id that RDS still owns<br /> for any other event. On the active side the id stays ic-&gt;i_cm_id and<br /> the connection&amp;#39;s shutdown destroys it, so that case returns 0.<br /> <br /> [achender: reject only on RDMA_CM_EVENT_CONNECT_REQUEST instead of<br /> bailing out for every event on a non-IB device, so that rdma_cm does<br /> not destroy connection ids RDS still tracks; drop a connection whose<br /> address resolved to a non-IB device before a route is resolved on it;<br /> changelog adjusted]

Impact