The Bluetooth BAP Broadcast Assistant GATT client in subsys/bluetooth/audio/bap_broadcast_assistant.c reassembled remote Broadcast Receive State data into a single file-static net_buf_simple (att_buf, BT_ATT_MAX_ATTRIBUTE_LEN = 512 bytes) shared by all connection instances, while the BUSY flag, long-read handle, and reset/offset state were per-connection.

When the device acts as a Broadcast Assistant connected to multiple Scan Delegator peripherals, notification and long-read callbacks from different connections interleave on the shared buffer: the append in notify_handler (net_buf_simple_add_mem at the not-busy branch) performs no tailroom check, so receive-state notifications from two or more delegators accumulate on the same 512-byte buffer and, with a sufficiently large configured ATT MTU (BT_L2CAP_TX_MTU up to 2000) and two-to-three concurrent connections, write past the buffer into adjacent .bss (net_buf_simple_add only asserts in debug builds).

Even below the overflow threshold, one connection's net_buf_simple_reset zeroes the shared length while another connection's reassembly and GATT read offset are in flight, mixing one peer's data into another's parse. A malicious or compromised Scan Delegator (or two colluding peers) over BLE can trigger this, causing out-of-bounds writes (memory corruption / denial of service) and cross-connection data corruption.

The fix moves the buffer into the per-connection instance struct so each connection reassembles into its own buffer. Affects Zephyr releases shipping the Broadcast Assistant with the shared buffer, including v4.4.0 and earlier.

Affected components

• subsys/bluetooth/audio/bap_broadcast_assistant.c

Affected versions

Zephyr releases shipping the BAP Broadcast Assistant with the shared static att_buf, including v4.4.0 and earlier; fixed on main by 0cd6158.

Fix

Fixed (merged) in 0cd6158

Projected fixed version: 4.5.0 (the fix is merged on main but not yet released; this forecast should be confirmed against the actual release).

Introduced by: Pre-existing Broadcast Assistant design using a single file-static att_buf shared across all connection instances; present at v4.4.0 and earlier.

Evidence

• subsys/bluetooth/audio/bap_broadcast_assistant.c:111 — per-connection instance array broadcast_assistants[CONFIG_BT_MAX_CONN]; pre-fix att_buf was a single file-static, so state was per-instance but the buffer was global.
• commit.diff:35-36 — removed NET_BUF_SIMPLE_DEFINE_STATIC(att_buf, BT_ATT_MAX_ATTRIBUTE_LEN); diff:26-27/100-101 add per-instance att_buf[512] + net_buf.
• subsys/bluetooth/audio/bap_broadcast_assistant.c:548 — net_buf_simple_add_mem(&inst->net_buf,...) in notify_handler has NO tailroom check (unlike the read callback at line 411); pre-fix this appended to the shared buffer.
• subsys/bluetooth/audio/bap_broadcast_assistant.c:411-421 — long-read callback bounds-checks tailroom on the (formerly shared) buffer, confirming the buffer is reused across connection callbacks.
• subsys/bluetooth/audio/bap_broadcast_assistant.c:343-347/472 — bap_long_read_reset() resets the buffer and offset is set from buf.len; pre-fix one connection's reset/offset affected another's data.
• include/zephyr/bluetooth/att.h:99 — BT_ATT_MAX_ATTRIBUTE_LEN = 512 (buffer size).
• subsys/bluetooth/audio/audio.c:276-286 — bt_audio_get_max_ntf_size returns MTU-3; subsys/bluetooth/host/Kconfig.l2cap:42 allows BT_L2CAP_TX_MTU up to 2000, so a single notification can be hundreds of bytes.
• lib/net_buf/buf_simple.c net_buf_simple_add — only __ASSERT_NO_MSG on tailroom; no runtime bound, so overflow is silent in production builds.
• git show v4.4.0:subsys/bluetooth/audio/bap_broadcast_assistant.c — shared static att_buf and unchecked notify-path add_mem present in v4.4.0 (reportable).

Patches

For more information

If you have any questions or comments about this advisory:

• Open an issue in zephyr
• Email us at Zephyr-vulnerabilities

embargo: 2026-07-11