An integer overflow condition exists in Bluetooth Host stack, within the bt_br_acl_recv routine a critical path for processing inbound BR/EDR L2CAP traffic.
conn_br.c
This is a simple overflow: hdr->len is attacker-controlled. If it holds 0xfffc, then acl_total_len be 65536, which wraps back to 0 due to the 16-bit width. This corrupted length is then used to clip the buffer
if (buf->len > acl_total_len)
buf->len = acl_total_len; // now 0At this point, the internal buffer state is desynchronized. Payload data is still present, but logic downstream will believe the buffer is empty, a silent discard. Worse, the upstream ACL reassembly guardrails are skipped entirely for BR/EDR (BT_CONN_TYPE_BR), so malformed packets arrive unfiltered.
This gives a remote, unauthenticated Bluetooth device the ability to push crafted packets that deplete CPU cycles and interrupt flow control. There's no memory corruption per se, but this is a clean DoS vector with protocol-aware precision. Given enough sustained traffic, this becomes operationally disruptive and may cause resource exhaustion or force a watchdog reset in constrained systems.
Mitigation: validate the hdr->len before arithmetic. Any addition that would exceed UINT16_MAX must be rejected.
if (sys_le16_to_cpu(hdr->len) > (UINT16_MAX - sizeof(*hdr))) {
LOG_ERR("L2CAP PDU length overflow");
net_buf_unref(buf);
return;
}This issue affects Zephyr 4.2.0. All BR/EDR-enabled targets should apply this patch. Bluetooth Classic should never trust length fields blindly, especially when arithmetic is involved.
Patches
main: #97370
For more information
If you have any questions or comments about this advisory:
embargo: 2025-12-13
0xf00sec Reporter
An integer overflow condition exists in Bluetooth Host stack, within the
bt_br_acl_recvroutine a critical path for processing inbound BR/EDR L2CAP traffic.conn_br.c
This is a simple overflow:
hdr->lenis attacker-controlled. If it holds0xfffc, thenacl_total_len be65536, which wraps back to 0 due to the 16-bit width. This corrupted length is then used to clip the bufferAt this point, the internal buffer state is desynchronized. Payload data is still present, but logic downstream will believe the buffer is empty, a silent discard. Worse, the upstream ACL reassembly guardrails are skipped entirely for
BR/EDR (BT_CONN_TYPE_BR), so malformed packets arrive unfiltered.This gives a remote, unauthenticated Bluetooth device the ability to push crafted packets that deplete CPU cycles and interrupt flow control. There's no memory corruption per se, but this is a clean DoS vector with protocol-aware precision. Given enough sustained traffic, this becomes operationally disruptive and may cause resource exhaustion or force a watchdog reset in constrained systems.
Mitigation: validate the hdr->len before arithmetic. Any addition that would exceed UINT16_MAX must be rejected.
This issue affects Zephyr 4.2.0. All BR/EDR-enabled targets should apply this patch. Bluetooth Classic should never trust length fields blindly, especially when arithmetic is involved.
Patches
main: #97370
For more information
If you have any questions or comments about this advisory:
embargo: 2025-12-13