Bluetooth Host connection reservation leak when multiple connectable advertising sets share an identity
The Bluetooth host pre-allocates a bt_conn object (a "reservation") from the fixed acl_conns[] pool for every connectable advertising set it starts, in le_adv_start_add_conn() in subsys/bluetooth/host/adv.c. When an incoming peripheral connection completes, find_pending_connect() in subsys/bluetooth/host/hci_core.c looked that reservation up using only the identity and the peer address, with a directed-then-undirected fallback, and had no knowledge of which advertising set actually terminated. With CONFIG_BT_EXT_ADV_MAX_ADV_SET > 1, where the LE Enhanced Connection Complete event is cached until the LE Advertising Set Terminated event identifies the set, this lookup can return the reservation belonging to a different, still-running advertising set. The defect is reachable over the air by any adjacent device. If an application runs two connectable extended advertising sets on the same identity — one undirected and one directed at a peer P (the common "directed reconnect to a bonded central while still accepting new centrals" pattern) — a remote initiator whose address maps to P connecting on the undirected set causes the directed set's reservation to be consumed instead. The initiator address is chosen freely by the remote device and is not authenticated at link establishment, so no bonding, pairing or prior relationship is required to trigger the mis-attribution. The undirected set's own reservation is then stranded: its BT_ADV_ENABLED flag has already been cleared, and le_ad
- Products
- zephyr
- Affected versions
- Not specified
- Fixed versions
- Not specified
- CVEs
- CVE-2026-81039
- Confirmed fixed CVEs
- Not specified
- Updated in this feed
- 30 Oct 2026, 16:00 UTC · Revision 1
Source evidence
Bluetooth Host connection reservation leak when multiple connectable advertising sets share an identity
core-cve · Original sourcePublished 26 Oct 2026, 16:08 UTC
The Bluetooth host pre-allocates a bt_conn object (a "reservation") from the fixed acl_conns[] pool for every connectable advertising set it starts, in le_adv_start_add_conn() in subsys/bluetooth/host/adv.c. When an incoming peripheral connection completes, find_pending_connect() in subsys/bluetooth/host/hci_core.c looked that reservation up using only the identity and the peer address, with a directed-then-undirected fallback, and had no knowledge of which advertising set actually terminated. With CONFIG_BT_EXT_ADV_MAX_ADV_SET > 1, where the LE Enhanced Connection Complete event is cached until the LE Advertising Set Terminated event identifies the set, this lookup can return the reservation belonging to a different, still-running advertising set. The defect is reachable over the air by any adjacent device. If an application runs two connectable extended advertising sets on the same identity — one undirected and one directed at a peer P (the common "directed reconnect to a bonded central while still accepting new centrals" pattern) — a remote initiator whose address maps to P connecting on the undirected set causes the directed set's reservation to be consumed instead. The initiator address is chosen freely by the remote device and is not authenticated at link establishment, so no bonding, pairing or prior relationship is required to trigger the mis-attribution. The undirected set's own reservation is then stranded: its BT_ADV_ENABLED flag has already been cleared, and le_ad
cve:CVE-2026-81039
zephyr
Fixed versions: Not specified
Complete source record
{
"id": "e368b62ea3880b39f64e9389c42c89ee1a07cafe26b56221bedcc38be67f2a3c",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-81039",
"method": "structured",
"payload": {
"kind": "advisory",
"title": "Bluetooth Host connection reservation leak when multiple connectable advertising sets share an identity",
"summary": "The Bluetooth host pre-allocates a bt_conn object (a \"reservation\") from the fixed acl_conns[] pool for every connectable advertising set it starts, in le_adv_start_add_conn() in subsys/bluetooth/host/adv.c. When an incoming peripheral connection completes, find_pending_connect() in subsys/bluetooth/host/hci_core.c looked that reservation up using only the identity and the peer address, with a directed-then-undirected fallback, and had no knowledge of which advertising set actually terminated. With CONFIG_BT_EXT_ADV_MAX_ADV_SET > 1, where the LE Enhanced Connection Complete event is cached until the LE Advertising Set Terminated event identifies the set, this lookup can return the reservation belonging to a different, still-running advertising set. The defect is reachable over the air by any adjacent device. If an application runs two connectable extended advertising sets on the same identity — one undirected and one directed at a peer P (the common \"directed reconnect to a bonded central while still accepting new centrals\" pattern) — a remote initiator whose address maps to P connecting on the undirected set causes the directed set's reservation to be consumed instead. The initiator address is chosen freely by the remote device and is not authenticated at link establishment, so no bonding, pairing or prior relationship is required to trigger the mis-attribution. The undirected set's own reservation is then stranded: its BT_ADV_ENABLED flag has already been cleared, and le_ad",
"evidence": "cve:CVE-2026-81039",
"products": [
{
"name": {
"value": "zephyr",
"evidence": "/containers/cna/affected/0/product"
},
"prerequisites": [],
"fixed_versions": [],
"affected_versions": []
}
],
"severity": "medium",
"structured": {
"id": "CVE-2026-81039",
"aliases": [
"CVE-2026-81039"
],
"metrics": [
{
"format": "CVSS",
"cvssV3_1": {
"version": "3.1",
"baseScore": 4.3,
"baseSeverity": "MEDIUM",
"vectorString": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L"
}
}
],
"affected": [
{
"vendor": "zephyrproject",
"product": "zephyr",
"versions": [
{
"status": "affected",
"version": "2.3.0",
"lessThan": "4.5.0",
"versionType": "semver"
}
],
"packageName": "zephyr",
"programFiles": [
"subsys/bluetooth/host/adv.c",
"subsys/bluetooth/host/hci_core.c",
"subsys/bluetooth/host/hci_core.h"
],
"collectionURL": "https://github.com/zephyrproject-rtos/zephyr",
"defaultStatus": "unaffected",
"programRoutines": [
{
"name": "bt_hci_le_adv_set_terminated"
},
{
"name": "bt_hci_le_enh_conn_complete"
},
{
"name": "find_pending_connect"
}
]
}
],
"modified": "2026-10-26T17:37:11.318Z",
"provider": "cve",
"references": [
"https://github.com/zephyrproject-rtos/zephyr/commit/b6a5e6e8aa9072a10a52420095af2d99f04d71fc",
"https://github.com/zephyrproject-rtos/zephyr/security/advisories/GHSA-5jw9-rp59-ch2q"
],
"provider_metadata": {
"adp": [
{
"title": "CISA ADP Vulnrichment",
"metrics": [
{
"other": {
"type": "ssvc",
"content": {
"id": "CVE-2026-81039",
"role": "CISA Coordinator",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"version": "2.0.3",
"timestamp": "2026-10-26T16:59:21.234445Z"
}
}
}
],
"providerMetadata": {
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP",
"dateUpdated": "2026-10-26T17:37:11.318Z"
}
}
],
"cna": {
"orgId": "e2e69745-5e70-4e92-8431-deb5529a81ad",
"shortName": "zephyr",
"dateUpdated": "2026-10-26T16:08:48.940Z"
}
}
},
"related_cves": [
{
"value": "CVE-2026-81039",
"evidence": "/cveMetadata/cveId"
}
],
"security_relevant": true,
"severity_evidence": "/containers/cna/metrics"
},
"source_id": "core-cve",
"document_id": 326393,
"published_at": "2026-10-26T16:08:48.94+00:00"
}