CVE-2026-92241
Bluetooth Classic AVRCP browsing channel can deadlock the Bluetooth receive thread, hanging the host
- Medium 5.7
Description
The AVRCP browsing channel's L2CAP receive-buffer callback, browsing_avrcp_l2cap_alloc_buf() in subsys/bluetooth/host/classic/avrcp.c, allocated from the shared avctp_browsing_rx_pool with K_FOREVER. L2CAP invokes that callback from the Bluetooth RX work queue thread (bt_workq, "BT RX WQ"), both for the head buffer of a new SDU and — through l2cap_br_alloc_frag() and net_buf_append_bytes() — for every further fragment of a reassembled SDU. That same thread is the only context that ever releases these buffers, after bt_l2cap_br_recv_seg() delivers a completed SDU and calls net_buf_unref(), so a wait taken there can never be satisfied. The pool holds CONFIG_BT_MAX_CONN + 1 buffers of CONFIG_BT_AVRCP_BROWSING_L2CAP_MTU bytes (two buffers of 339 bytes in the default configuration). A connected browsing peer can drain it because bt_l2cap_br_recv_seg() in subsys/bluetooth/host/classic/l2cap_br.c accepts the SDU length declared in an SAR_START segment without bounding it by br_chan->rx.mtu: a peer that announces a large SDU and then streams continuation segments forces one pool buffer per segment-worth of data. Once the pool is empty the next allocation blocks forever inside the callback. Triggering the flaw requires a build with CONFIG_BT_CLASSIC and the experimental CONFIG_BT_AVRCP_BROWSING option, an application that registers AVRCP callbacks, and a BR/EDR peer that has established the AVRCP control channel and then the browsing channel, which requires an encrypted (paired) link. No malformed packet is needed — a few hundred bytes of ordinary segmented L2CAP traffic suffice. The consequence is a permanent hang of the whole Bluetooth host, not just of AVRCP: the blocked thread drains bt_dev.rx_queue for all HCI ACL data and low-priority events and also runs the host's internal work items, so all connections stop being serviced and the state is unrecoverable without a reboot. There is no memory-corruption or information-disclosure component. The fix allocates with K_NO_WAIT, so an empty pool now yields a local-busy indication or a channel disconnect that the application can recover from.
Key facts
- Published
- 13 Nov 2026
- Last changed
- 13 Nov 2026
- Assigned by
- zephyr
- EPSS
- 0.147% likely to be exploited in the next 30 days, higher than 3.959% of CVEs (scores for 15 Nov 2026)
Severity scores
Each score is shown as its source gave it. They are not averaged or merged.
- 5.7CVSS 3.1, Mediumfrom the CNA (zephyr)
CVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Historical context and remediation
This reference retains the original CVE publication date. A recent record update does not mean a new attack occurred.
No separately sourced impact summary is available on this page yet. Consult the description, version data and dated exploitation evidence.
No explicit remediation statement is available on this page yet. Consult the original record and vendor references before choosing a fix.
Version statuses below come from the CNA. An “unaffected” version is not necessarily a currently supported release or proof of a patch date. EPSS is a dated risk estimate, not a count of historical attacks.
Affected products
| Vendor | Product | Versions |
|---|---|---|
| zephyrproject | zephyr |
|
Timeline
- 13 Nov 2026 Published