CVE-2026-18748 Lectura fuera de límites en el manejo del elemento de información de códec A2DP de Bluetooth Classic
El host de Bluetooth Classic A2DP copiaba solo los primeros 8 bytes de un elemento de información de códec enviado por un par AVDTP, pero conservaba la longitud elegida por el atacante, y luego usaba esa longitud inconsistente al responder un GET_CONFIGURATION. Un par BR/EDR emparejado puede provocar una lectura fuera de límites y filtrar memoria adyacente por el aire.
CVSS 3.1
- Probabilidad de explotación0,2 %
- Explotada activamenteNo confirmada
- Exploit públicoNo conocido
Afectados
zephyrproject zephyr
desde 4.3.0 hasta 4.4.2
Qué hacer
- Verificá si usás zephyr y en qué versión.
- Actualizá a la versión corregida que indique el fabricante en su aviso o aplicá su mitigación.
- Revisá registros y accesos de los sistemas expuestos para descartar un uso previo.
Calculadora CVSS
CVSS 3.1 · 3.5 BAJA
CVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
- Vector de ataqueRed adyacente
- Complejidad del ataqueBaja
- Privilegios requeridosBajos
- Interacción del usuarioNinguna
- AlcanceSin cambio
- ConfidencialidadBaja
- IntegridadNinguna
- DisponibilidadNinguna
Descripción original
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.
Referencias (2)
Resumen traducido automáticamente de la descripción original. Fuente: Nureq Monitor. Cómo funciona.