CVE-2026-18748

NiskieCVSS 3.5

Opublikowano: 21/10/2026(UTC)Zaktualizowano: 23/10/2026(UTC)Przetłumaczono: 22/10/2026(UTC)NVD NIST

Prawdopodobieństwo exploitacji (EPSS)

Niskie ryzyko

0.16%

Percentyl 5 - wyżej niż 5% wszystkich znanych CVE

Streszczenie

Podatność w stosie Bluetooth Classic A2DP (Zephyr) polega na tym, że struktura bt_a2dp_codec_ie przechowuje pole długości len oraz tablicę codec_ie[] o stałym rozmiarze 8 bajtów. Gdy zdalny peer AVDTP wyśle codec IE dłuższy niż 8 bajtów, funkcje a2dp_process_config_ind(), bt_a2dp_get_config_cb() i bt_a2dp_set_config_cb() kopiują tylko pierwsze 8 bajtów, ale zachowują pełną, wybraną przez atakującego długość w polu len. Później konsumenci ufają temu len, co prowadzi do odczytu poza granicami bufora i ujawnienia sąsiedniej pamięci RAM sparowanemu peerowi BR/EDR.

Ocena ryzyka

Sparowany zdalny peer BR/EDR może spowodować ujawnienie ograniczonego obszaru sąsiedniej pamięci RAM aplikacji (do około 245 bajtów poza tablicą 8-bajtową) poprzez wysłanie zbyt dużego codec IE w SET_CONFIGURATION, a następnie żądanie konfiguracji przez GET_CONFIGURATION. Wymaga to włączonych opcji CONFIG_BT_CLASSIC i CONFIG_BT_A2DP oraz lokalnego endpointu zarejestrowanego dla kodeka innego niż SBC.

Rekomendacja

Zaktualizuj stos Bluetooth do wersji zawierającej poprawkę, która zastępuje stałą BT_A2DP_MAX_IE_LENGTH konfigurowalnym CONFIG_BT_A2DP_CODEC_MAX_IE_LEN i odrzuca odebrane IE przekraczające ten limit zamiast je obcinać. Do czasu wdrożenia poprawki ogranicz ekspozycję, wyłączając A2DP lub rejestrując wyłącznie endpointy SBC, jeśli to możliwe.

Powiązane podatności

Oryginalny opis (angielski, źródło NVD)

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.

Dane podatności pochodzą z NVD (NIST) · CISA KEV · EPSS