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.

Read the original CVE record.

Affected products

VendorProductVersions
zephyrprojectzephyr
  • Default status: unaffected
  • 4.4.0 up to but excluding 4.5.0 (affected)

Timeline

  1. 13 Nov 2026 Published

Weakness

References