Description

The LE Audio Broadcast Sink in subsys/bluetooth/audio/bap_broadcast_sink.c copies subgroup metadata from a received Basic Audio Announcement (BASE) into the static Broadcast Audio Scan Service parameter structure mod_src_param without any bounds check. In base_subgroup_meta_cb() the destination element was selected as mod_src_param.subgroups[mod_src_param.num_subgroups] with no test against ARRAY_SIZE(mod_src_param.subgroups) (sized by CONFIG_BT_BAP_BASS_MAX_SUBGROUPS, default 1), and the metadata was copied with memcpy() using the raw on-air length returned by bt_bap_base_get_subgroup_codec_meta() into a metadata array sized by CONFIG_BT_AUDIO_CODEC_CFG_MAX_METADATA_SIZE (default 4). The BASE validator bt_bap_base_get_base_from_ad() only checks structural consistency and permits up to ~24 subgroups and metadata LTVs of ~240 octets. The defect is reached from the periodic advertising receive callback: pa_recv() → bt_data_parse() → pa_decode_base() → update_recv_state_base() → bt_bap_base_foreach_subgroup() → base_subgroup_meta_cb(). Every broadcast sink registers a scan-delegator receive state at creation (bt_bap_broadcast_sink_create() calls broadcast_sink_add_src()), and CONFIG_BT_BAP_BROADCAST_SINK depends on CONFIG_BT_BAP_SCAN_DELEGATOR, so the path is active in every broadcast-sink build once the device is periodic-advertising-synced. An attacker in radio range who operates a broadcast source the device syncs to — or who impersonates the advertiser address and SID of one already in use, periodic advertising data being unauthenticated — can change the BASE at will; each new BASE is re-parsed. A crafted BASE therefore writes attacker-chosen bytes past the end of a fixed static object in .bss: up to roughly 236 bytes for an oversized metadata LTV, plus whole struct bt_bap_bass_subgroup records for each subgroup beyond CONFIG_BT_BAP_BASS_MAX_SUBGROUPS. This is memory corruption of adjacent Bluetooth-audio state reachable with no pairing, bonding or GATT connection, with a potential for remote code execution in the Bluetooth RX thread; in addition, the unvalidated metadata_len is forwarded to bt_bap_scan_delegator_mod_src(), which neither clamps it nor rejects it, leading to a further copy into the receive state and to out-of-bounds memory being disclosed in the BASS receive-state notification sent to a connected Broadcast Assistant. The fix rejects a BASE carrying more subgroups than the receive state can hold (discarding the update entirely) and omits metadata that does not fit rather than copying it, and additionally honours the previously-ignored error return of the subgroup decode pass.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "8.8",
  "pubDate": "2026-10-09T08:16:54.693Z",
  "pubdate": "2026-10-09T08:16:54.693Z",
  "executiveSummary": "A critical out-of-bounds (OOB) write vulnerability exists in the LE Audio Broadcast Sink implementation within the Bluetooth subsystem.\nThe vulnerability is caused by the lack of bounds checking when parsing metadata from a received Basic Audio Announcement (BASE).\nAn unauthenticated attacker within radio range can leverage this flaw by broadcasting a crafted BASE, triggering memory corruption in the .bss segment.\nThe exploit path is active in any device with CONFIG_BT_BAP_BROADCAST_SINK enabled once the device is synchronized with periodic advertising.\nSuccessful exploitation may lead to remote code execution (RCE) in the Bluetooth RX thread, as well as potential information disclosure of adjacent memory states when communicating with a Broadcast Assistant.\nThis vulnerability requires no pairing, bonding, or GATT-level authentication, making it highly accessible to nearby malicious actors capable of impersonating or hosting a Bluetooth broadcast source.",
  "technicalDetails": "The root cause of the vulnerability is an unchecked memory copy operation within base_subgroup_meta_cb() in subsys/bluetooth/audio/bap_broadcast_sink.c. The function processes metadata from a BASE frame and copies it into the mod_src_param.subgroups structure without validating the input length or the number of subgroups against defined array limits (CONFIG_BT_BAP_BASS_MAX_SUBGROUPS and CONFIG_BT_AUDIO_CODEC_CFG_MAX_METADATA_SIZE).\nThe attack flow begins at the periodic advertising receive callback: pa_recv() → bt_data_parse() → pa_decode_base() → update_recv_state_base() → bt_bap_base_foreach_subgroup() → base_subgroup_meta_cb(). Because periodic advertising data is unauthenticated, an attacker can broadcast a malformed BASE that bypasses the structural validator bt_bap_base_get_base_from_ad(). The validator permits up to 24 subgroups, significantly exceeding the default configuration limit of 1.\nWhen base_subgroup_meta_cb() executes, it uses the raw on-air length provided by the BASE to perform a memcpy(). By providing an oversized metadata LTV (up to ~240 octets), an attacker can overwrite adjacent objects in the .bss memory section. Additionally, the index used to access mod_src_param.subgroups is not bounded, allowing an attacker to overwrite subsequent struct bt_bap_bass_subgroup records.\nFurthermore, the unvalidated length is propagated to bt_bap_scan_delegator_mod_src(). This function subsequently performs additional copies of the malicious data into the receive state. This secondary action can be leveraged for information disclosure, as the OOB data may be included in the BASS receive-state notifications sent to a connected Broadcast Assistant via GATT, potentially leaking sensitive memory contents.\nThe impact includes reliable memory corruption of critical Bluetooth-audio state data. In the context of the Bluetooth RX thread, this corruption offers a pathway to arbitrary code execution. Given the nature of the Bluetooth stack's execution environment, this facilitates remote compromise without any user interaction or established trust relationship, as the vulnerability is reachable purely via over-the-air reception of broadcast data."
}