---
id: "CVE-2026-99166"
kind: "vulnerability"
aliases: ["CVE-2026-99166"]
title: "Linux kernel: RDS listener on iWARP device crashes the kernel on connect"
severity: "unknown"
cvss: null
epss: null
exploited: false
status: "open"
category: "runtime"
products: []
ecosystems: []
tags: ["iwarp", "linux-kernel", "rdma", "rds", "runtime", "self-hosted"]
not_affected_if: ["infiniband-only", "rds-not-loaded"]
published_at: "2026-10-28T11:17:37+00:00"
first_seen_at: "2026-10-28T11:32:36+00:00"
updated_at: "2026-10-28T11:35:42+00:00"
sources: [{"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-99166", "first_seen_at": "2026-10-28T11:32:36+00:00"}]
---

# Linux kernel: RDS listener on iWARP device crashes the kernel on connect

The Linux kernel RDS (Reliable Datagram Sockets) RDMA connection manager read an uninitialized transport pointer when the RDMA device was not InfiniBand, such as an iWARP RNIC like siw. A connect request arriving on such a device causes a kernel NULL dereference and crash.

_Summary, check and fix written by a model from the sources; labelled as such._

## How to check

- `uname -r` and compare against the kernel release that carries the fix in the NVD entry
- Check whether the RDS module is loaded with `lsmod | grep rds`
- Check for iWARP RDMA devices with `rdma link show` or `ibv_devices`

## Fix

- Update the Linux kernel to a release that includes the upstream commit 'net: rds: fix uninitialized trans dereference in CM event handler'
- Until patched, unload RDS with `modprobe -r rds_rdma rds` if RDS is not needed

## Timeline

- 2026-10-28T11:32:36+00:00 nvd https://nvd.nist.gov/vuln/detail/CVE-2026-99166

## From the sources

In the Linux kernel, the following vulnerability has been resolved:

net: rds: fix uninitialized trans dereference in CM event handler

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->cm_handle_connect(),
and (with a connection context) in the ROUTE_RESOLVED and
ESTABLISHED cases.

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
(&trans->cm_handle_connect) in the iw_cm_wq workqueue.

GCC masks the bug in default builds by folding the uninitialized
load into &rds_ib_transport; Clang-built kernels take the real
uninitialized path and oops.

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->route.path_rec, and the ROUTE_RESOLVED case writes
path_rec[0].sl before it calls into the transport.

The iWARP transport was dropped long ago and IB is the only
transport left, so make that explicit: initialize trans to
&rds_ib_transport at declaration, drop the conditional assignment,
reject a connect request that arrives on a non-IB device, and drop a
connection whose address resolved to one instead of resolving a
route on it.  The rejection is limited to RDMA_CM_EVENT_CONNECT_REQUEST
on purpose: a non-zero return from the handler makes rdma_cm destroy
the id the event was delivered on, which is right for the request's
freshly created id but would free a connection id that RDS still owns
for any other event.  On the active side the id stays ic->i_cm_id and
the connection's shutdown destroys it, so that case returns 0.

[achender: reject only on RDMA_CM_EVENT_CONNECT_REQUEST instead of
 bailing out for every event on a non-IB device, so that rdma_cm does
 not destroy connection ids RDS still tracks; drop a connection whose
 address resolved to a non-IB device before a route is resolved on it;
 changelog adjusted]

---

_Free to read at a human pace. An API with keys and an MCP server are in preparation; early access: hello@infrastack.ai_