CVE-2026-18748: Out-of-bounds read in Bluetooth Classic A2DP codec information element handling
The Bluetooth Classic A2DP host stores a codec Information Element (IE) in struct bta2dpcodecie, a one-byte len field plus a fixed 8-byte codecie[] array. When an AVDTP peer sent a codec IE longer than 8 bytes, a2dpprocessconfigind() 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 bta2dpstream via stream->codecconfig. bta2dpgetconfigcb() and bta2dpsetconfigcb() had the same truncate-the-copy-but-keep-the-length pattern.
Every later consumer trusts len. In particular the responder for an incoming AVDTP GETCONFIGURATION, a2dpgetconfigind(), executes netbufaddmem(rspbuf, &ep->stream->codecconfig.codecie[0], ep->stream->codecconfig.len), so a paired BR/EDR peer that first sends a SETCONFIGURATION 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. codecconfig is the last member of struct bta2dpstream, so the read runs into memory adjacent to the application's stream object. The same inconsistency is also handed to the configreq(), reconfigreq() and getconfigrsp() application callbacks, where a natural memcpy() of len bytes performs a further out-of-bounds read.
Reaching the on-air disclosure requires CONFIGBTCLASSIC with CONFIGBTA2DP, an AVDTP peer that has completed pairing (the AVDTP L2CAP channel requires BTSECURITYL2), and a local endpoint registered for a non-SBC codec — BTA2DPMPEG1/BTA2DPMPEG2/BTA2DPATRAC/BTA2DPVENDOR via BTA2DPEPINIT() — because the SBC branch already pins the IE length to 4 bytes. The bta2dpgetconfigcb() response path has no such gate and hands the lying length to any application. There is no out-of-bounds write: the netbuf 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 BTA2DPMAXIELENGTH with the configurable CONFIGBTA2DPCODECMAXIELEN (default 8, range 4–253), sizes codecie[] 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.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
Use CONFIG_BT_A2DP_CODEC_MAX_IE_LEN to size codec_ie[] and reject received codec Information Elements longer than the configured maximum; the documented default is 8 bytes, with an allowed range of 4–253.
Bluetooth Classic A2DP CONFIG_BT_A2DP_CODEC_MAX_IE_LEN = 8
Event History
Frequently Asked Questions
Which deployments are exposed?
Deployments using the Bluetooth Classic A2DP host and an application's bt_a2dp_stream can be exposed when they accept codec configuration from a paired BR/EDR AVDTP peer. The over-read can reach memory adjacent to the application's stream object.
What does an attacker need to do to trigger the information disclosure?
The attacker needs to be a paired BR/EDR peer. They can send SET_CONFIGURATION with a codec IE longer than 8 bytes, then issue GET_CONFIGURATION so the stack returns data using the attacker-controlled stored length.
What data can be disclosed?
The GET_CONFIGURATION response can include bytes read past the fixed 8-byte codec_ie array, up to roughly 245 bytes. Because codec_config is the final member of bt_a2dp_stream, the disclosed bytes may come from memory adjacent to the application's stream object.
Are only inbound configuration requests relevant?
No. The same copy-truncation while retaining the original length is present in a2dp_process_config_ind(), bt_a2dp_get_config_cb(), and bt_a2dp_set_config_cb(). Later consumers trust the stored length, including the responder for an incoming GET_CONFIGURATION request.