{
  "cveId": "CVE-2026-99166",
  "url": "https://patchblox.com/security/cve/CVE-2026-99166",
  "summary": "CVE-2026-99166 is fixed in linux on 1 platform by DEBIAN-CVE-2026-99166 (version 6.12.115-2), released November 3, 2026. It is not reported as exploited. Patch Radar priority: Routine.",
  "title": "net: rds: fix uninitialized trans dereference in CM event handler",
  "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-\u003Ecm_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 (\u0026trans-\u003Ecm_handle_connect) in the iw_cm_wq workqueue.  GCC masks the bug in default builds by folding the uninitialized load into \u0026rds_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-\u003Eroute.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 \u0026rds_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\u0027s 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-\u003Ei_cm_id and the connection\u0027s 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-28T11:17:37Z",
  "severity": "Moderate",
  "cvss": 5.5,
  "epss": 0.00183,
  "epssPercentile": 0.07966,
  "priority": "Routine",
  "priorityTier": 4,
  "exploited": false,
  "vendorExploited": false,
  "disclosed": false,
  "vendorAdvisory": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-99166",
  "fixes": [
    {
      "platform": "linux",
      "product": "linux",
      "release": "Debian 13.5 (trixie)",
      "fixedVersion": "6.12.115-2",
      "fix": "DEBIAN-CVE-2026-99166",
      "url": "https://patchblox.com/security/fix/linux/debian-cve-2026-99166",
      "released": "2026-11-03T18:58:21Z"
    }
  ],
  "noFixYet": [],
  "dataAsOf": "2026-11-08T00:53:09Z",
  "attribution": {
    "text": "Data: Patchblox Patch Radar",
    "url": "https://patchblox.com/security/patch-radar",
    "terms": "https://patchblox.com/security/patch-radar/use-the-data"
  }
}