Vulnerability briefing · 2026-10-28 16:47 IST

CVE-2026-99166

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]

UNRATED · N/ALinux

Executive briefing

This record describes a reported software or hardware weakness. The description and CVSS rating are source metadata; practical risk depends on whether your environment uses an affected product/version and whether the vulnerable component is reachable and configured in an exploitable way.

Assessment status: No CISA KEV listing is currently recorded in this local feed. This does not prove the vulnerability is not exploited.

Severity & exploitability

— / 10 CVSS

CVSS vector:

Impacted products and platforms

Specific affected product configurations are not currently available in the NVD record. Review vendor advisories and validate applicability against your asset inventory.

How it works and what it could affect

The NVD description is the authoritative short summary currently available for this record. A detailed technical mechanism is not inferred when the source record does not provide one.

Review the CVSS attack characteristics above to understand whether exploitation is network/local, whether privileges or user interaction are required, and which confidentiality, integrity or availability impacts are scored.

Remediation and recommended response

  1. Identify exposure: compare the affected product and version ranges below with your asset inventory, software bill of materials, endpoint inventory and externally exposed services.
  2. Remediate: review the linked vendor security advisory or patch notes, upgrade to a fixed release, or apply the vendor-provided workaround if an upgrade cannot be completed.
  3. Mitigate while patching: restrict network access to the vulnerable service, disable the affected feature where operationally safe, and monitor vendor/CERT advisories for updated guidance.
  4. Validate: confirm the fixed version or mitigation on representative systems, run a vulnerability rescan, and retain change evidence.

No vendor remediation link has been identified in the available NVD references yet. Check the affected vendor's security advisory portal before applying changes.

Exploit intelligence & references

No CISA KEV match is recorded in the latest successful catalog refresh. This is not a guarantee that public proof-of-concept code or exploitation does not exist.

Sources: NVD and CISA KEV when available. Vendor confirmation remains the final authority for fixed versions and workarounds.

Open NVD record ← Back to CVE Watch