{"dataType":"CVE_RECORD","dataVersion":"5.2","cveMetadata":{"cveId":"CVE-2026-92241","assignerOrgId":"e2e69745-5e70-4e92-8431-deb5529a81ad","state":"PUBLISHED","assignerShortName":"zephyr","dateReserved":"2026-09-15T19:52:34.955Z","datePublished":"2026-11-13T14:03:47.349Z","dateUpdated":"2026-11-13T14:03:47.349Z"},"containers":{"cna":{"providerMetadata":{"orgId":"e2e69745-5e70-4e92-8431-deb5529a81ad","shortName":"zephyr","dateUpdated":"2026-11-13T14:03:47.349Z"},"title":"Bluetooth Classic AVRCP browsing channel can deadlock the Bluetooth receive thread, hanging the host","descriptions":[{"lang":"en","value":"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.\n\nThe 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.\n\nTriggering 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.\n\nThe 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."}],"affected":[{"vendor":"zephyrproject","product":"zephyr","collectionURL":"https://github.com/zephyrproject-rtos/zephyr","packageName":"zephyr","defaultStatus":"unaffected","programFiles":["subsys/bluetooth/host/classic/avrcp.c"],"programRoutines":[{"name":"browsing_avrcp_l2cap_alloc_buf"}],"versions":[{"version":"4.4.0","status":"affected","versionType":"semver","lessThan":"4.5.0"}]}],"references":[{"url":"https://github.com/zephyrproject-rtos/zephyr/commit/c8c2438f05165397347613b44dd8e9eaa1243139","name":"Fix commit","tags":["patch"]},{"url":"https://github.com/zephyrproject-rtos/zephyr/security/advisories/GHSA-8vpg-4235-9qjj","name":"GHSA-8vpg-4235-9qjj"}],"metrics":[{"format":"CVSS","cvssV3_1":{"version":"3.1","vectorString":"CVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H","baseScore":5.7,"baseSeverity":"MEDIUM"}}],"problemTypes":[{"descriptions":[{"lang":"en","description":"dos","cweId":"CWE-833","type":"CWE"}]}],"x_generator":{"engine":"cvelib 1.8.0"}}}}