CVE Catalog

CVE-2026-18748

LowCVSS 3.5
Published: Updated: Translated: NVD NIST

Exploitation Probability (EPSS)

Low risk
0.16%

5th percentile - higher than 5% of all known CVEs

Summary

A vulnerability in the Bluetooth Classic A2DP host stack (Zephyr) involves struct bt_a2dp_codec_ie, which stores a one-byte len field plus a fixed 8-byte codec_ie[] array. When an AVDTP peer sends a codec IE longer than 8 bytes, a2dp_process_config_ind(), bt_a2dp_get_config_cb() and bt_a2dp_set_config_cb() copy only the first 8 bytes but keep the full attacker-chosen length in len. Later consumers trust len, leading to an out-of-bounds read and disclosure of adjacent RAM to a paired BR/EDR peer.

Risk Assessment

A paired remote BR/EDR peer can cause disclosure of a bounded region of adjacent application RAM (up to roughly 245 bytes past the 8-byte array) by sending an oversized codec IE in SET_CONFIGURATION and then requesting the configuration back via GET_CONFIGURATION. This requires CONFIG_BT_CLASSIC and CONFIG_BT_A2DP enabled and a local endpoint registered for a non-SBC codec.

Recommendation

Update the Bluetooth stack to a version containing the fix that replaces the hardcoded BT_A2DP_MAX_IE_LENGTH with the configurable CONFIG_BT_A2DP_CODEC_MAX_IE_LEN and rejects received IEs exceeding it instead of silently truncating. Until patched, limit exposure by disabling A2DP or registering only SBC endpoints where possible.

Related vulnerabilities

Original NVD description (English source)

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.

Vulnerability data from NVD (NIST) · CISA KEV · EPSS