{
  "affected": [
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:12",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:13",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:14",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "details": "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'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-\u003ei_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]",
  "id": "DEBIAN-CVE-2026-99166",
  "modified": "2026-10-29T05:47:22.772673056Z",
  "published": "2026-10-28T11:17:37.043Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://security-tracker.debian.org/tracker/CVE-2026-99166"
    }
  ],
  "upstream": [
    "CVE-2026-99166"
  ]
}