Description
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]
Published: 2026-10-28
Score: n/a
EPSS: n/a
KEV: No
Impact: Denial of Service – kernel crash via uninitialized pointer dereference in RDS RDMA event handler
Action: Apply patch
AI Analysis

Impact

The vulnerability originates from an uninitialized pointer 'trans' in the RDS RDMA CM event handler. When an RDMA connect request arrives on a non‑InfiniBand device such as iWARP, the handler dereferences this pointer and triggers a kernel oops. The result is an abrupt kernel crash, which can be leveraged for a denial‑of‑service attack by repeatedly sending RDS connection requests to a vulnerable listener.

Affected Systems

Linux kernel distributions that ship the RDS (Remote Data Services) module with RDMA support on iWARP or similar RNIC devices are affected. Any configuration enabling RDS on such RDMA transports may be vulnerable.

Risk and Exploitability

The flaw is exploitable locally or remotely via crafted RDMA connect requests, since no prior authentication is required beyond the RDMA CM protocol. EPSS data is unavailable and the vulnerability is not in the KEV catalog, but the high severity of a kernel crash makes it a critical asset‑risk event. Mitigation requires updating the kernel to a release that includes the stated commit or applying the patch directly.

Generated by OpenCVE AI on October 28, 2026 at 12:01 UTC.

Remediation

No solution or workaround provided in the CVE record.

OpenCVE Recommended Actions

  • Update the kernel to a version that incorporates the commit fixing the uninitialized trans dereference (e.g., kernel releases after the commit 492ba6ac1b1ffb8a06ff52db0825c1af2cdb28c8).
  • If a kernel upgrade cannot be performed immediately, disable RDS support (CONFIG_RDS) or disable RDMA support in the kernel configuration (e.g., CONFIG_RDS_RDMA or related iWARP settings) and rebuild the kernel to eliminate the vulnerable module.
  • After applying the update or rebuild, ensure that no RDS listener remains bound to an iWARP RDMA device; monitor system logs for any remaining kernel oops incidents related to RDMA to confirm mitigation.

Generated by OpenCVE AI on October 28, 2026 at 12:01 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Wed, 28 Oct 2026 10:45:00 +0000

Type Values Removed Values Added
Description 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]
Title net: rds: fix uninitialized trans dereference in CM event handler
First Time appeared Linux
Linux linux Kernel
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
References

Subscriptions

Linux Linux Kernel
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2026-10-28T10:35:18.050Z

Reserved: 2026-09-25T10:25:14.398Z

Link: CVE-2026-99166

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Received

Published: 2026-10-28T11:17:37.043

Modified: 2026-10-28T11:17:37.043

Link: CVE-2026-99166

cve-icon Redhat

No data.

cve-icon OpenCVE Enrichment

Updated: 2026-10-28T12:15:14Z

Weaknesses

No weakness.