{
  "affected": [
    {
      "ranges": [
        {
          "database_specific": {
            "extracted_events": [
              {
                "introduced": "1.6.0"
              },
              {
                "fixed": "4.4.2"
              }
            ],
            "source": [
              "AFFECTED_FIELD",
              "REFERENCES"
            ]
          },
          "events": [
            {
              "introduced": "d4e799d77a36eaf6d678b357c207411ec32b2d62"
            },
            {
              "fixed": "2738ee921ba61ba2e644c95bceba302896dd8c19"
            }
          ],
          "repo": "https://github.com/zephyrproject-rtos/zephyr",
          "type": "GIT"
        }
      ]
    }
  ],
  "aliases": [
    "GHSA-hx89-rm6c-hjrh"
  ],
  "database_specific": {
    "cna_assigner": "zephyr",
    "cwe_ids": [
      "CWE-666"
    ],
    "osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/15xxx/CVE-2026-15460.json"
  },
  "details": "The Bluetooth Classic (BR/EDR) L2CAP receive handler bt_l2cap_br_recv() in subsys/bluetooth/host/classic/l2cap_br.c dispatched inbound data PDUs based only on the destination channel ID, without checking that the target channel had reached the BT_L2CAP_CONNECTED state. A dynamic channel is assigned its RX CID and added to the connection's channel list while still in BT_L2CAP_CONNECTING (and later BT_L2CAP_CONFIG) — before configuration completes and, for PSMs that require security, before the peer is authenticated (l2cap_br_conn_req()).\n\nBecause the channel is already findable by bt_l2cap_br_lookup_rx_cid() during this window, a remote peer within radio range can send a data PDU addressed to that CID and have it processed on a not-yet-established channel. The dispatch keys off channel fields (BR_CHAN(chan)-\u003erx.mode, rx.mps) that are only initialized during configuration by l2cap_br_conf(); since channel objects are pooled and bt_l2cap_br_chan_del() does not reset rx.mode or the reassembly buffer _sdu, a reused channel can carry stale state into the CONNECTING window and route the frame into the retransmission/flow-control path (bt_l2cap_br_ret_fc_recv()) with stale parameters and a possibly stale _sdu pointer.\n\nThe impact is delivery of attacker data to upper-layer protocol handlers on a half-open (and possibly unauthenticated) channel, plus operation on stale or partially initialized channel state on reused channel objects — leading to channel/link teardown (denial of service) and, in the stale-_sdu case, a dangling-pointer condition. The fix adds an explicit BR_CHAN(chan)-\u003estate \u003c BT_L2CAP_CONNECTED guard that drops any data received before the channel is fully connected.",
  "id": "CVE-2026-15460",
  "modified": "2026-09-12T03:30:34.987095895Z",
  "published": "2026-09-09T22:40:46.492Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/15xxx/CVE-2026-15460.json"
    },
    {
      "type": "ADVISORY",
      "url": "https://github.com/zephyrproject-rtos/zephyr/security/advisories/GHSA-hx89-rm6c-hjrh"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-15460"
    },
    {
      "type": "FIX",
      "url": "https://github.com/zephyrproject-rtos/zephyr/commit/2738ee921ba61ba2e644c95bceba302896dd8c19"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/zephyrproject-rtos/zephyr"
    }
  ],
  "schema_version": "1.9.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Missing channel-state validation in Zephyr Bluetooth Classic L2CAP receive path"
}