{"api_version":"1","generated_at":"2026-10-21T22:12:12+00:00","cve":"CVE-2026-18748","urls":{"html":"https://cve.report/CVE-2026-18748","api":"https://cve.report/api/cve/CVE-2026-18748.json","docs":"https://cve.report/api","cve_org":"https://www.cve.org/CVERecord?id=CVE-2026-18748","nvd":"https://nvd.nist.gov/vuln/detail/CVE-2026-18748"},"summary":{"title":"Out-of-bounds read in Bluetooth Classic A2DP codec information element handling","description":"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.\n\nEvery 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.\n\nReaching 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.\n\nThe 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.","state":"PUBLISHED","assigner":"zephyr","published_at":"2026-10-21 19:17:02","updated_at":"2026-10-21 19:17:02"},"problem_types":["CWE-125","CWE-125 bounds"],"metrics":[{"version":"3.1","source":"vulnerabilities@zephyrproject.org","type":"Secondary","score":"3.5","severity":"LOW","vector":"CVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N","data":{"version":"3.1","vectorString":"CVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N","baseScore":3.5,"baseSeverity":"LOW","attackVector":"ADJACENT_NETWORK","attackComplexity":"LOW","privilegesRequired":"LOW","userInteraction":"NONE","scope":"UNCHANGED","confidentialityImpact":"LOW","integrityImpact":"NONE","availabilityImpact":"NONE"}},{"version":"3.1","source":"CNA","type":"CVSS","score":"3.5","severity":"LOW","vector":"CVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N","data":{"baseScore":3.5,"baseSeverity":"LOW","vectorString":"CVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N","version":"3.1"}}],"references":[{"url":"https://github.com/zephyrproject-rtos/zephyr/security/advisories/GHSA-6qq5-25mp-x5rg","name":"https://github.com/zephyrproject-rtos/zephyr/security/advisories/GHSA-6qq5-25mp-x5rg","refsource":"vulnerabilities@zephyrproject.org","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://github.com/zephyrproject-rtos/zephyr/commit/c5f649f4714e625362fbaa93ffd7419f9c27342b","name":"https://github.com/zephyrproject-rtos/zephyr/commit/c5f649f4714e625362fbaa93ffd7419f9c27342b","refsource":"vulnerabilities@zephyrproject.org","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-18748","name":"CVE Program record","refsource":"CVE.ORG","tags":["canonical"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-18748","name":"NVD vulnerability detail","refsource":"NVD","tags":["canonical","analysis"]}],"affected":[{"source":"CNA","vendor":"zephyrproject","product":"zephyr","version":"affected 4.3.0 4.4.2 semver","platforms":[]}],"timeline":[],"solutions":[],"workarounds":[],"exploits":[],"credits":[],"nvd_cpes":[],"vendor_comments":[],"enrichments":{"kev":null,"epss":null,"legacy_qids":[]},"source_records":{"cve_program":{"containers":{"cna":{"affected":[{"collectionURL":"https://github.com/zephyrproject-rtos/zephyr","defaultStatus":"unaffected","packageName":"zephyr","product":"zephyr","programFiles":["include/zephyr/bluetooth/classic/a2dp.h","subsys/bluetooth/host/classic/Kconfig","subsys/bluetooth/host/classic/a2dp.c"],"programRoutines":[{"name":"a2dp_get_config_ind"},{"name":"a2dp_process_config_ind"},{"name":"bt_a2dp_get_config_cb"}],"vendor":"zephyrproject","versions":[{"lessThanOrEqual":"4.4.2","status":"affected","version":"4.3.0","versionType":"semver"}]}],"descriptions":[{"lang":"en","value":"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.\n\nEvery 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.\n\nReaching 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.\n\nThe 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."}],"metrics":[{"cvssV3_1":{"baseScore":3.5,"baseSeverity":"LOW","vectorString":"CVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N","version":"3.1"},"format":"CVSS"}],"problemTypes":[{"descriptions":[{"cweId":"CWE-125","description":"bounds","lang":"en","type":"CWE"}]}],"providerMetadata":{"dateUpdated":"2026-10-21T18:19:29.937Z","orgId":"e2e69745-5e70-4e92-8431-deb5529a81ad","shortName":"zephyr"},"references":[{"name":"Fix commit","tags":["patch"],"url":"https://github.com/zephyrproject-rtos/zephyr/commit/c5f649f4714e625362fbaa93ffd7419f9c27342b"},{"name":"GHSA-6qq5-25mp-x5rg","url":"https://github.com/zephyrproject-rtos/zephyr/security/advisories/GHSA-6qq5-25mp-x5rg"}],"title":"Out-of-bounds read in Bluetooth Classic A2DP codec information element handling","x_generator":{"engine":"cvelib 1.8.0"}}},"cveMetadata":{"assignerOrgId":"e2e69745-5e70-4e92-8431-deb5529a81ad","assignerShortName":"zephyr","cveId":"CVE-2026-18748","datePublished":"2026-10-21T18:19:29.937Z","dateReserved":"2026-08-03T21:22:14.200Z","dateUpdated":"2026-10-21T18:19:29.937Z","state":"PUBLISHED"},"dataType":"CVE_RECORD","dataVersion":"5.2"},"nvd":{"publishedDate":"2026-10-21 19:17:02","lastModifiedDate":"2026-10-21 19:17:02","problem_types":["CWE-125","CWE-125 bounds"],"metrics":{"cvssMetricV31":[{"source":"vulnerabilities@zephyrproject.org","type":"Secondary","cvssData":{"version":"3.1","vectorString":"CVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N","baseScore":3.5,"baseSeverity":"LOW","attackVector":"ADJACENT_NETWORK","attackComplexity":"LOW","privilegesRequired":"LOW","userInteraction":"NONE","scope":"UNCHANGED","confidentialityImpact":"LOW","integrityImpact":"NONE","availabilityImpact":"NONE"},"exploitabilityScore":2.1,"impactScore":1.4}]},"configurations":[]},"legacy_mitre":{"record":{"CveYear":"2026","CveId":"18748","Ordinal":"1","Title":"Out-of-bounds read in Bluetooth Classic A2DP codec information e","CVE":"CVE-2026-18748","Year":"2026"},"notes":[{"CveYear":"2026","CveId":"18748","Ordinal":"1","NoteData":"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.\n\nEvery 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.\n\nReaching 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.\n\nThe 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.","Type":"Description","Title":"Out-of-bounds read in Bluetooth Classic A2DP codec information e"}]}}}