EUVD-2026-107483Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessPair with target over BR/EDR
-
DeliveryOpen AVDTP signalling channel
-
ExploitSend SET_CONFIGURATION with oversized codec IE
-
ExecutionRequest GET_CONFIGURATION for stream
-
PersistStack reads past 8-byte array
-
ImpactAdjacent RAM disclosed to peer
Vulnerability Assessment
| Weakness |
CWE
ASVS 5.0
V15 - Secure Coding and Architecture Bounds checking, read limits
MITRE ATT&CK
1 technique across 1 tactic: Collection The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | Exploitation requires a specific build and runtime posture: the firmware must be compiled with CONFIG_BT_CLASSIC and CONFIG_BT_A2DP, and the local application must register at least one NON-SBC codec endpoint (BT_A2DP_MPEG1, BT_A2DP_MPEG2, BT_A2DP_ATRAC, or BT_A2DP_VENDOR via BT_A2DP_EP_INIT) - SBC endpoints are NOT affected because the SBC branch pins the IE length to 4 bytes. The attacker must be a BR/EDR peer that has completed pairing, since the AVDTP L2CAP channel enforces BT_SECURITY_L2; there is no unauthenticated path on the responder. Limiting factors that reduce real-world risk: Bluetooth adjacent range only (no remote/Internet reach), mandatory prior pairing, the non-SBC codec gate, and the fact that the disclosure is bounded (~245 bytes of adjacent RAM) and read-only with no code execution or write primitive. |
| Impact | This is a genuinely low-priority issue whose signals are internally consistent rather than conflicting. The CVSS 3.1 vector (AV:A/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N, base 3.5 LOW) aligns with the description: the attack is Bluetooth adjacent-only (AV:A), requires a peer that has already completed BR/EDR pairing (PR:L, consistent with the stated BT_SECURITY_L2 requirement on the AVDTP L2CAP channel), and yields only a bounded confidentiality loss (C:L) with no integrity or availability impact - the description explicitly confirms there is NO out-of-bounds write because the net_buf tailroom check bounds the destination. No EPSS score, SSVC decision, KEV listing, or POC was provided in the input: there is no public exploit identified at time of analysis, and the vulnerability is NOT in CISA KEV. The practical risk is further depressed by three stacked preconditions (compile-time CONFIG_BT_CLASSIC+CONFIG_BT_A2DP, a successfully paired peer, and a registered NON-SBC codec endpoint). Net: a low-CVSS, low-real-risk information-disclosure bug affecting a narrow embedded configuration - worth patching as part of routine Zephyr updates but not an emergency. |
| Exploit ScenarioDerived | A BR/EDR device that has already paired with a Zephyr-based audio product abuses the AVDTP signalling channel: it sends a SET_CONFIGURATION carrying a codec Information Element longer than 8 bytes, which the stack truncates on copy but records with the attacker-chosen oversized length. The attacker then issues GET_CONFIGURATION, and the responder emits up to ~245 bytes of RAM adjacent to the application's bt_a2dp_stream object back over the air. No public exploit code is identified; exploitation is adjacent-range (Bluetooth) with low complexity but requires prior pairing. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 21, 2026
An out-of-bounds read in the Zephyr RTOS Bluetooth Classic A2DP host stack allows a paired BR/EDR peer to retrieve roughly 245 bytes of adjacent RAM from the victim device over the air. The bug is reachable only in firmware built with CONFIG_BT_CLASSIC and CONFIG_BT_A2DP that registers at least one non-SBC codec endpoint (MPEG1, MPEG2, ATRAC or vendor), because the SBC path pins the codec IE length to 4 bytes; the attacker must also have completed pairing since the AVDTP L2CAP channel enforces BT_SECURITY_L2 (CVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N). Impact is limited to read-only disclosure of a bounded region of RAM with no write primitive or code execution, and no public exploit code was identified at time of analysis.
RemediationAI
Apply the upstream fix commit c5f649f4714e625362fbaa93ffd7419f9c27342b (documented at https://github.com/zephyrproject-rtos/zephyr/security/advisories/GHSA-6qq5-25mp-x5rg), which removes the hardcoded BT_A2DP_MAX_IE_LENGTH, sizes codec_ie[] from the new CONFIG_BT_A2DP_CODEC_MAX_IE_LEN option (default 8, range 4-253), and rejects any received IE exceeding that bound with BT_AVDTP_UNSUPPORTED_CONFIGURAION instead of silently truncating, so len can no longer exceed the valid byte count; note this is an upstream commit, so a tagged release containing it should be confirmed before relying on version numbers alone. If firmware cannot be rebuilt immediately, the highest-value compensating control is to register only SBC endpoints (or none) on affected devices, since the SBC branch pins the IE length to 4 bytes and closes the responder path, at the cost of losing MPEG/AAC/ATRAC/vendor codec support; be aware this does not cover the bt_a2dp_get_config_cb() callback path. Because exploitation requires a fully paired BR/EDR peer within radio range, additionally restrict discoverable/connectable pairing windows, require pairing authorization or bonding whitelists, and reduce A2DP exposure on devices that do not need Classic audio, accepting the trade-off of reduced usability for legitimate headsets and audio accessories.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
struct bt_a2dp_codec_ie pairs a one-byte len field with a fixed 8-byte codec_ie[] array, and a2dp_process_config_ind() in subsys/bluetooth/host/classic/a2dp.c broke the invariant between them: when an AVDTP peer supplied a codec IE longer than 8 bytes, the handler copied only the first 8 bytes but stored the attacker-chosen full length, 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() repeated the same truncate-the-copy-but-keep-the-length pattern. This is CWE-125 because every downstream consumer trusts len: a2dp_get_config_ind() answers an incoming AVDTP GET_CONFIGURATION with net_buf_add_mem(rsp_buf, &ep->stream->codec_config.codec_ie[0], ep->stream->codec_config.len), so a SET_CONFIGURATION carrying an oversized IE followed by a GET_CONFIGURATION causes an over-read past the 8-byte array and transmits the leaked bytes in the response. Since codec_config is the last member of struct bt_a2dp_stream, the read lands in memory adjacent to the application's stream object. The same lying length is also handed to the config_req(), reconfig_req() and get_config_rsp() application callbacks, where an application memcpy() of len bytes performs a further out-of-bounds read. The net_buf tailroom check bounds the destination buffer only, which is why there is no out-of-bounds write and the net effect is confined to information disclosure.
Know when Zephyr gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
AV:A/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
Bluetooth adjacent (AV:A); requires a paired peer so PR:L; low-complexity signalling abuse (AC:L); bounded adjacent-RAM read only, so C:L and I:N/A:N.
Primary rating from Vendor (zephyr).
CVSS VectorVendor: zephyr
DescriptionCVE.org
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.
Threat Intelligence Overview
NVD
CVE.org
EPSS
GitHub
VulDB
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
A buffer overflow occurs when a program writes more data to a memory buffer than it was allocated to hold, causing the excess data to spill into adjacent memory regions.
Information disclosure occurs when an application unintentionally exposes sensitive data that aids attackers in reconnaissance or directly compromises security.
Potential off-by-one buffer overflow vulnerability in the Zephyr fuse file system. Rated critical severity (CVSS 10.0),
An out-of-bounds write in the Zephyr RTOS DNS resolver (dns_unpack_name()) lets a crafted DNS response corrupt memory on
Possible variant of CVE-2021-3434 in function le_ecred_reconf_req. Rated critical severity (CVSS 9.8), this vulnerabilit
Unchecked user input length in /subsys/net/l2/wifi/wifi_shell.c can cause buffer overflows. Rated critical severity (CVS
Potential buffer overflow vulnerability in the Zephyr CAN bus subsystem. Rated critical severity (CVSS 9.8), this vulner
Integer Underflow in 6LoWPAN IPHC Header Uncompression in Zephyr. Rated critical severity (CVSS 9.8), this vulnerability
Buffer overflow in Zephyr USB DFU DNLOAD. Rated critical severity (CVSS 9.8), this vulnerability is remotely exploitable
DOS: Incorrect 802154 Frame Validation for Omitted Source / Dest Addresses. Rated critical severity (CVSS 9.8), this vul
zephyr-rtos version 1.12.0 contains a NULL base pointer reference vulnerability in sys_ring_buf_put(), sys_ring_buf_get(
Potential buffer overflow vulnerabilities n the Zephyr Bluetooth subsystem. Rated critical severity (CVSS 9.6), this vul
The documentation specifies that the BT_GATT_PERM_READ_LESC and BT_GATT_PERM_WRITE_LESC defines for a Bluetooth characte
Potential buffer overflows in the Bluetooth subsystem due to asserts being disabled in /subsys/bluetooth/host/hci_core.c
Exploit-DB