Cloudanix VulnDB

CVE-2026-99166

None

CVSS

—

EPSS

0.2%

Published

Oct 28, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A networking bug in the Linux kernel can make the entire system crash when certain high-speed network connections are attempted, interrupting services until the machine is restarted.

Exploitation
Remote Unauthenticated
Attacker needs
None
Complexity
Moderate
Impact
Denial Of Service
Component
OS kernel
Class
Memory Corruption
Remediation
Patch
Effort
Medium
Patch risk
Low

What it actually does

Uninitialized pointer dereference in rds_rdma_cm_event_handler_cmn allowing wild load or NULL dereference when an RDMA_CM event arrives on a non-InfiniBand device such as iWARP, resulting in kernel panic in the iw_cm_wq workqueue.

Why it matters to the business

Systems using the RDS protocol over RDMA-capable network interfaces experience immediate kernel crashes and denial of service upon receiving connection requests or route resolution events, disrupting network services and requiring reboots.

How an attack unfolds

An attacker initiates an RDMA connection attempt to a vulnerable RDS listener bound to an iWARP RNIC or forces the active side to resolve an address on such a device; the handler dereferences the uninitialized trans pointer in the CONNECT_REQUEST, ROUTE_RESOLVED, or ESTABLISHED cases, triggering a crash before any transport-specific handling occurs.

How to fix it

Apply the upstream kernel patch that initializes trans to &rds_ib_transport at declaration, explicitly rejects RDMA_CM_EVENT_CONNECT_REQUEST on non-IB devices, and drops connections that resolve to non-IB devices; rebuild and deploy the fixed kernel across affected systems.

How to confirm the fix worked

Verify the presence of the fix by inspecting the rds_rdma_cm_event_handler_cmn function for unconditional initialization of trans and the added non-IB rejection logic; confirm no oops occurs when testing connect requests on iWARP devices after the update.

Typical attack path

  1. Identify or control a network path to a host running RDS over a non-IB RDMA device
  2. Send an RDMA_CM connect request or trigger address resolution that binds to an iWARP RNIC
  3. Trigger the uninitialized trans dereference inside rds_rdma_cm_event_handler_cmn
  4. Cause kernel panic via NULL or wild pointer load in the workqueue

How to detect it

Search kernel logs and dmesg for oops or panic messages referencing rds_rdma_cm_event_handler_cmn, iw_cm_wq, or uninitialized trans dereference; look for preceding RDMA_CM events on non-IB devices and stack traces showing cm_handle_connect or path_rec writes.

  • rds_rdma_cm_event_handler_cmn
  • iw_cm_wq
  • trans->cm_handle_connect
  • path_rec[0].sl
  • RDMA_CM_EVENT_CONNECT_REQUEST on non-IB device

What your security team should do

  • Patch affected kernels immediately given the one-day publication window and ease of remote trigger
  • Disable RDS or restrict RDMA interfaces to InfiniBand-only devices until patched
  • Monitor kernel logs for oops signatures in rds and iw_cm_wq
  • Audit RDMA device configurations to ensure only IB hardware remains exposed to RDS listeners

The record

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]

Affected packages

Ecosystem Package Introduced Fixed