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.
Published: 2026-10-21
Score: 3.5 Low
EPSS: < 1% Very Low
KEV: No
Impact: Out-of-bounds read
Action: Patch
AI Analysis

Impact

A flaw in Zephyr’s Bluetooth Classic A2DP processing hands an attacker‑supplied length field that exceeds the actual buffer size to higher‑level code. The bug allows a remote peer to read beyond the 8‑byte array in the codec information element and exploit the memory adjacent to the stream structure, resulting in a bounded disclosure of kernel memory. The vulnerability is a typical out‑of‑bounds read (CWE‑125) that does not write data, so it does not corrupt state and is limited to leaking a small but potentially sensitive region of memory.

Affected Systems

The affected product is Zephyr RTOS, specifically the Bluetooth Classic A2DP host implementation compiled with CONFIG_BT_CLASSIC and CONFIG_BT_A2DP. The flaw exists when the host registers for a non‑SBC codec (BT_A2DP_MPEG1, BT_A2DP_MPEG2, BT_A2DP_ATRAC, or vendor specific) and a paired AVDTP peer sends a codec information element larger than the 8‑byte limit. The issue is present in any Zephyr source tree that includes the unpatched A2DP code (e.g., pre‑commit c5f649f4714e6).

Risk and Exploitability

The CVSS score of 3.5 indicates low severity, but the EPSS score is not available, so the current likelihood of exploitation is unknown. The vulnerability does not appear in the CISA KEV catalog and there is no known active exploitation. Attackers need only a paired BR/EDR A2DP peer with full L2CAP channel access, which is a realistic scenario for devices using Bluetooth audio. Because the bug leads only to bounded memory disclosure, a full compromise is unlikely, yet the risk of leaking credentials or secrets should not be ignored, especially in hostile environments.

Generated by OpenCVE AI on October 22, 2026 at 04:13 UTC.

Remediation

No solution or workaround provided in the CVE record.

OpenCVE Recommended Actions

  • Apply the latest Zephyr RTOS release that incorporates the fix in commit c5f649f4714e625362fbaa93ffd7419f9c27342b and ensures the configuration option CONFIG_BT_A2DP_CODEC_MAX_IE_LEN is set to a value no greater than 253.
  • Configure the build to prohibit non‑SBC codecs if the application does not require them, or enforce the maximum codec IE length by adjusting CONFIG_BT_A2DP_CODEC_MAX_IE_LEN to 4 or 8 as appropriate.
  • If an update cannot be applied immediately, temporarily disable the A2DP host or reject oversized codec information elements by validating the length against the configured maximum before copying into the stream structure.

Generated by OpenCVE AI on October 22, 2026 at 04:13 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Fri, 23 Oct 2026 22:30:00 +0000

Type Values Removed Values Added
Metrics ssvc

{'options': {'Automatable': 'no', 'Exploitation': 'none', 'Technical Impact': 'partial'}, 'version': '2.0.3'}

Thu, 22 Oct 2026 02:15:00 +0000

Type Values Removed Values Added
First Time appeared Zephyrproject
Zephyrproject zephyr
Vendors & Products Zephyrproject
Zephyrproject zephyr

Wed, 21 Oct 2026 18:30:00 +0000

Type Values Removed Values Added
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.
Title Out-of-bounds read in Bluetooth Classic A2DP codec information element handling
Weaknesses CWE-125
References
Metrics cvssV3_1

{'score': 3.5, 'vector': 'CVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N'}

Subscriptions

Zephyrproject Zephyr
cve-icon MITRE

Status: PUBLISHED

Assigner: zephyr

Published:

Updated: 2026-11-04T05:01:21.030Z

Reserved: 2026-08-03T21:22:14.200Z

Link: CVE-2026-18748

cve-icon Vulnrichment

Updated: 2026-10-23T20:42:54.775Z

cve-icon NVD

Status : Awaiting Analysis

Published: 2026-10-21T19:17:02.503

Modified: 2026-11-04T05:18:47.233

Link: CVE-2026-18748

cve-icon Redhat

No data.

cve-icon OpenCVE Enrichment

Updated: 2026-10-22T04:15:09Z

Weaknesses