FKIE_CVE-2026-15460
Vulnerability from fkie_nvd - Published: 2026-09-09 23:16 - Updated: 2026-09-09 23:16
Severity
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 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.
References
Impacted products
| Vendor | Product | Version |
|---|
{
"affected": [
{
"affectedData": [
{
"collectionURL": "https://github.com/zephyrproject-rtos/zephyr",
"defaultStatus": "unaffected",
"packageName": "zephyr",
"product": "zephyr",
"programFiles": [
"subsys/bluetooth/host/classic/l2cap_br.c"
],
"programRoutines": [
{
"name": "bt_l2cap_br_chan_del"
},
{
"name": "bt_l2cap_br_recv"
},
{
"name": "bt_l2cap_br_ret_fc_recv"
},
{
"name": "l2cap_br_conn_req"
}
],
"vendor": "zephyrproject",
"versions": [
{
"lessThan": "4.4.2",
"status": "affected",
"version": "1.6.0",
"versionType": "semver"
}
]
}
],
"source": "vulnerabilities@zephyrproject.org"
}
],
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "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\u0027s channel list while still in BT_L2CAP_CONNECTING (and later BT_L2CAP_CONFIG) \u2014 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 \u2014 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",
"lastModified": "2026-09-09T23:16:54.617",
"metrics": {
"cvssMetricV31": [
{
"cvssData": {
"attackComplexity": "LOW",
"attackVector": "ADJACENT_NETWORK",
"availabilityImpact": "LOW",
"baseScore": 5.4,
"baseSeverity": "MEDIUM",
"confidentialityImpact": "NONE",
"integrityImpact": "LOW",
"privilegesRequired": "NONE",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:L",
"version": "3.1"
},
"exploitabilityScore": 2.8,
"impactScore": 2.5,
"source": "vulnerabilities@zephyrproject.org",
"type": "Secondary"
}
]
},
"published": "2026-09-09T23:16:54.617",
"references": [
{
"source": "vulnerabilities@zephyrproject.org",
"url": "https://github.com/zephyrproject-rtos/zephyr/commit/2738ee921ba61ba2e644c95bceba302896dd8c19"
},
{
"source": "vulnerabilities@zephyrproject.org",
"url": "https://github.com/zephyrproject-rtos/zephyr/security/advisories/GHSA-hx89-rm6c-hjrh"
}
],
"sourceIdentifier": "vulnerabilities@zephyrproject.org",
"vulnStatus": "Received",
"weaknesses": [
{
"description": [
{
"lang": "en",
"value": "CWE-666"
}
],
"source": "vulnerabilities@zephyrproject.org",
"type": "Secondary"
}
]
}
Loading…
Loading…
Experimental. This forecast is provided for visualization only and may change without notice. Do not use it for operational decisions.
Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Loading…
The MITRE ATT&CK techniques below are AI-generated suggestions, inferred from the description of the
vulnerability by the CIRCL/vulnerability-attack-technique-classification-roberta-base
model, served locally by ML-Gateway.
They have not been verified by an analyst and are provided for guidance only.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Loading…
Loading…