AEGLIX vulnerability intelligence
CVE-2026-18748
LOW · CVSS 3.5 · Awaiting Analysis
Published: 2026-10-21 · Updated: 2026-10-23 · Source: NVD
Stored catalog record
Source record retrieved 2026-10-28T10:20:22.018455+00:00. Scheduled imports handle updates; this page does not assert that the provider was queried just now.
Vulnerability overview
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.
Patch review priority
Assess exposure and vendor guidance
- No higher-priority signal is available in the current stored evidence.
FIRST EPSS: 0.20% · percentile 10.1 · score date 2026-10-27.
EPSS estimates probability of exploitation in the next 30 days. It does not measure your exposure or prove exploitation. The elevated threshold is 10%; CISA KEV takes precedence. About FIRST EPSS ↗
Severity and scoring
- CVSS score
- 3.5 · LOW
- CVSS version
- 3.1
- CVSS vector
- CVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
- Weaknesses
- CWE-125
CVSS measures technical severity; it does not establish whether this vulnerability is being exploited in your environment.
Known exploitation and remediation
Not listed in the CISA catalog retrieved for this record. This does not establish that exploitation has not occurred.
Verify affected versions and patch availability in the vendor advisory before making changes.
Affected products and versions
NVD has not supplied affected-version configurations for this record. Check the vendor references below.