---
id: CVE-2026-15460
title: >-
  Missing channel-state validation in Zephyr Bluetooth Classic L2CAP receive
  path
summary: >-
  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 reach…
severity: medium
cvss: 5.4
cvssVector: 'CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:L'
cvssSource: cna
cwe:
  - CWE-666
vendor: zephyrproject
product: zephyr
affected:
  - zephyr >= 1.6.0 < 4.4.2
ssvc:
  exploitation: none
  automatable: 'no'
  technicalImpact: partial
  timestamp: '2026-09-10T17:50:21.102172Z'
published: '2026-09-09'
updated: '2026-09-10'
sourceUpdated: '2026-09-10T17:50:55.003Z'
source: CVEORG
sourceUrl: 'https://www.cve.org/CVERecord?id=CVE-2026-15460'
references:
  - url: >-
      https://github.com/zephyrproject-rtos/zephyr/commit/2738ee921ba61ba2e644c95bceba302896dd8c19
    label: Fix commit
  - url: >-
      https://github.com/zephyrproject-rtos/zephyr/security/advisories/GHSA-hx89-rm6c-hjrh
    label: GHSA-hx89-rm6c-hjrh
tags:
  - cve.org
epss: 0.00159
epssPercentile: 0.04226
ingestedAt: '2026-09-11T11:32:42.883Z'
---

## Overview

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()).

Because 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)->rx.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.

The 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)->state < BT_L2CAP_CONNECTED guard that drops any data received before the channel is fully connected.

## Affected

- `zephyr >= 1.6.0 < 4.4.2`

## Remediation

Refer to the linked advisories for vendor-supplied fixes and affected version ranges.