CVSS 3.1
5.7 mediumCVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HCVE-2026-92241 Bluetooth Classic AVRCP browsing channel can deadlock the Bluetooth receive thread, hanging the host
Medium (5.7) in zephyrproject zephyr.
On this page
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.
Severity
- CWE
- CWE-833 Deadlock
- Published
- Modified
- Assigned by
- zephyr (CNA)
- NVD analysis
- Awaiting analysis
- Record from
- the NVD, synced
Ask an AI about this CVE
Show the prompt
Explain CVE-2026-92241 for an engineer deciding whether to act. Use https://cve.bz/api/public/cves/CVE-2026-92241?via=ask-ai-copy and https://cve.bz/cve/CVE-2026-92241?via=ask-ai-copy as the source of truth: what is affected and which versions fix it, whether it is in CISA KEV, public exploits, and its EPSS (an internet-wide 30-day estimate of exploitation activity, not a forecast for my systems). If they give no fixed versions, use the CVE record https://cveawg.mitre.org/api/cve/CVE-2026-92241 or the vendor advisory, not third-party mirrors. Tell me how to check whether I am affected and how to verify a fix. Cite the sources and say where they are uncertain.Opens a third-party assistant; its answer is its own, not cve.bz's. The prompt holds only this CVE's id and public links.
Badge for a README or a site
An image that stays current: it is drawn from the data each time it is fetched (a host that proxies images, as GitHub does, may show its copy for a while). Markdown:
[](https://cve.bz/cve/CVE-2026-92241)
HTML:
<a href="https://cve.bz/cve/CVE-2026-92241"><img src="https://cve.bz/cve/badge/CVE-2026-92241.svg" alt="CVE-2026-92241"></a>
Affected
Versions
From the CNA's record in the CVE List.
| Product | Affected |
|---|---|
| zephyrproject zephyr | from 4.4.0 before 4.5.0 |
Attack patterns (CAPEC)
- CAPEC-25 Forced Deadlock Likelihood: Low · Severity: High
The attack patterns MITRE's CAPEC relates to this record's weaknesses, as MITRE names them. Credits.