Out-of-bounds read in Bluetooth Classic A2DP codec information element handling
Summary
| CVE | CVE-2026-18748 |
|---|---|
| State | PUBLISHED |
| Assigner | zephyr |
| Source Priority | CVE Program / NVD first with legacy fallback |
| Published | 2026-10-21 19:17:02 UTC |
| Updated | 2026-10-21 19:17:02 UTC |
| Description | The Bluetooth Classic A2DP host stores a codec Information Element (IE) in struct bt_a2dp_codec_ie, a one-byte len field plus a fixed 8-byte codec_ie[] array. When an AVDTP peer sent a codec IE longer than 8 bytes, a2dp_process_config_ind() in subsys/bluetooth/host/classic/a2dp.c copied only the first 8 bytes but assigned the full, attacker-chosen length to len, and then persisted that inconsistent structure into the application's struct bt_a2dp_stream via stream->codec_config. bt_a2dp_get_config_cb() and bt_a2dp_set_config_cb() had the same truncate-the-copy-but-keep-the-length pattern. Every later consumer trusts len. In particular the responder for an incoming AVDTP GET_CONFIGURATION, a2dp_get_config_ind(), executes net_buf_add_mem(rsp_buf, &ep->stream->codec_config.codec_ie[0], ep->stream->codec_config.len), so a paired BR/EDR peer that first sends a SET_CONFIGURATION carrying an oversized codec IE and then requests the configuration back causes the stack to read up to roughly 245 bytes past the end of the 8-byte array and transmit them in the response. codec_config is the last member of struct bt_a2dp_stream, so the read runs into memory adjacent to the application's stream object. The same inconsistency is also handed to the config_req(), reconfig_req() and get_config_rsp() application callbacks, where a natural memcpy() of len bytes performs a further out-of-bounds read. Reaching the on-air disclosure requires CONFIG_BT_CLASSIC with CONFIG_BT_A2DP, an AVDTP peer that has completed pairing (the AVDTP L2CAP channel requires BT_SECURITY_L2), and a local endpoint registered for a non-SBC codec — BT_A2DP_MPEG1/BT_A2DP_MPEG2/BT_A2DP_ATRAC/BT_A2DP_VENDOR via BT_A2DP_EP_INIT() — because the SBC branch already pins the IE length to 4 bytes. The bt_a2dp_get_config_cb() response path has no such gate and hands the lying length to any application. There is no out-of-bounds write: the net_buf tailroom check bounds the destination, so the impact is limited to disclosure of a bounded region of adjacent RAM to the peer. The fix replaces the hardcoded BT_A2DP_MAX_IE_LENGTH with the configurable CONFIG_BT_A2DP_CODEC_MAX_IE_LEN (default 8, range 4–253), sizes codec_ie[] from it, and rejects any received IE that exceeds it instead of silently truncating, so len can no longer exceed the number of valid bytes. |
Risk And Classification
Primary CVSS: v3.1 3.5 LOW from [email protected]
CVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
Problem Types: CWE-125 | CWE-125 bounds
| Version | Source | Type | Score | Severity | Vector |
|---|---|---|---|---|---|
| 3.1 | [email protected] | Secondary | 3.5 | LOW | CVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N |
| 3.1 | CNA | CVSS | 3.5 | LOW | CVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N |
CVSS v3.1 Breakdown
Attack Vector
AdjacentAttack Complexity
LowPrivileges Required
LowUser Interaction
NoneScope
UnchangedConfidentiality
LowIntegrity
NoneAvailability
NoneCVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
Vendor Declared Affected Products
| Source | Vendor | Product | Version | Platforms |
|---|---|---|---|---|
| CNA | Zephyrproject | Zephyr | affected 4.3.0 4.4.2 semver | Not specified |
References
| Reference | Source | Link | Tags |
|---|---|---|---|
| github.com/zephyrproject-rtos/zephyr/security/advisories/GHSA-6qq5-25mp-... | [email protected] | github.com | |
| github.com/zephyrproject-rtos/zephyr/commit/c5f649f4714e625362fbaa93ffd7... | [email protected] | github.com | |
| CVE Program record | CVE.ORG | www.cve.org | canonical |
| NVD vulnerability detail | NVD | nvd.nist.gov | canonical, analysis |
No vendor comments have been submitted for this CVE.
There are currently no legacy QID mappings associated with this CVE.