CVE-2026-92241: Bluetooth Classic AVRCP browsing channel can deadlock the Bluetooth receive thread, hanging the host
The AVRCP browsing channel's L2CAP receive-buffer callback, browsingavrcpl2capallocbuf() in subsys/bluetooth/host/classic/avrcp.c, allocated from the shared avctpbrowsingrxpool with KFOREVER. L2CAP invokes that callback from the Bluetooth RX work queue thread (btworkq, "BT RX WQ"), both for the head buffer of a new SDU and — through l2capbrallocfrag() and netbufappendbytes() — for every further fragment of a reassembled SDU. That same thread is the only context that ever releases these buffers, after btl2capbrrecvseg() delivers a completed SDU and calls netbufunref(), so a wait taken there can never be satisfied.
The pool holds CONFIGBTMAXCONN + 1 buffers of CONFIGBTAVRCPBROWSINGL2CAPMTU bytes (two buffers of 339 bytes in the default configuration). A connected browsing peer can drain it because btl2capbrrecvseg() in subsys/bluetooth/host/classic/l2capbr.c accepts the SDU length declared in an SARSTART segment without bounding it by brchan->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 CONFIGBTCLASSIC and the experimental CONFIGBTAVRCPBROWSING 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 btdev.rxqueue 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 KNOWAIT, so an empty pool now yields a local-busy indication or a channel disconnect that the application can recover from.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
Change the allocation from the shared avctp_browsing_rx_pool to use K_NO_WAIT instead of K_FOREVER.
AVRCP browsing L2CAP receive-buffer callback (browsing_avrcp_l2cap_alloc_buf()) buffer allocation timeout = K_NO_WAIT
Event History
Frequently Asked Questions
Who can trigger the denial of service?
A connected Bluetooth Classic peer using the AVRCP browsing channel can trigger it. The vector is adjacent-network and requires low privileges, with no user interaction.
Are default configurations affected?
Yes. In the default configuration, the shared browsing receive pool has two 339-byte buffers, making it possible for a connected peer to exhaust the pool and deadlock the Bluetooth receive work queue.
What does exploitation require?
The peer must send an SAR_START segment declaring a large SDU, then stream continuation segments. The receive path does not bound the declared SDU length by the channel receive MTU, causing buffer consumption for each segment-worth of reassembled data.
What is the operational impact?
Once the shared receive pool is empty, the next allocation waits forever in the Bluetooth RX work queue. Because that same thread is responsible for releasing the buffers, the host's Bluetooth receive processing hangs.