{"id":"CVE-2026-92241","aliases":[],"cve":{"records":[{"id":"CVE-2026-92241","source":"zephyr","state":"PUBLISHED","reasons":[],"replacements":[],"disputed":false,"unsupportedWhenAssigned":false,"reserved":"2026-09-15T19:52:34.955Z","published":"2026-11-13T14:03:47.349Z","modified":"2026-11-13T14:03:47.349Z"}],"publishers":[{"name":"zephyr","role":"CNA","organizationId":"e2e69745-5e70-4e92-8431-deb5529a81ad","modified":"2026-11-13T14:03:47.349Z"}],"references":[{"url":"https://github.com/zephyrproject-rtos/zephyr/commit/c8c2438f05165397347613b44dd8e9eaa1243139","tags":["patch"],"source":"zephyr"},{"url":"https://github.com/zephyrproject-rtos/zephyr/security/advisories/GHSA-8vpg-4235-9qjj","tags":[],"source":"zephyr"}],"weaknesses":[{"id":"CWE-833","description":"dos","source":"zephyr"}],"applicability":[],"prioritization":[]},"title":"Bluetooth Classic AVRCP browsing channel can deadlock the Bluetooth receive thread, hanging the host","titleSource":"zephyr","descriptionSource":"zephyr","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.\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.","score":5.7,"severity":"medium","published":"2026-11-13T14:03:47.349Z","modified":"2026-11-13T14:03:47.349Z","withdrawn":false,"knownExploited":false,"affected":[],"products":[{"vendor":"zephyrproject","name":"zephyr","platforms":[],"versions":[{"version":"4.4.0","status":"affected","lessThan":"4.5.0","versionType":"semver"}],"defaultStatus":"unaffected","cpes":[],"source":"zephyr","url":"https://www.cve.org/CVERecord?id=CVE-2026-92241"}],"remediation":[],"references":["https://github.com/zephyrproject-rtos/zephyr/commit/c8c2438f05165397347613b44dd8e9eaa1243139","https://github.com/zephyrproject-rtos/zephyr/security/advisories/GHSA-8vpg-4235-9qjj"],"sources":[{"name":"CVE","id":"CVE-2026-92241","modified":"2026-11-13T14:03:47.349Z","url":"https://www.cve.org/CVERecord?id=CVE-2026-92241"}],"assessments":[{"source":"zephyr","vector":"CVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H","score":5.7}],"sourceAffected":[],"observedAt":"2026-11-13T19:09:08.766Z","kev":{"status":"not-listed","checkedAt":"2026-11-15T02:25:31.038Z"},"coverage":[{"source":"NVD","status":"refresh-failed","attemptedAt":"2026-11-13T19:30:36.225Z"},{"source":"GHSA","status":"no-result","checkedAt":"2026-11-13T19:30:37.132Z","attemptedAt":"2026-11-13T19:30:37.132Z"},{"source":"EUVD","status":"available","checkedAt":"2026-11-13T19:30:37.193Z","attemptedAt":"2026-11-13T19:30:37.193Z"},{"source":"EPSS","status":"no-result","checkedAt":"2026-11-13T19:30:36.855Z","attemptedAt":"2026-11-13T19:30:36.855Z"}],"evidence":[{"source":"ENISA EUVD","id":"EUVD-2026-125340","url":"https://euvd.enisa.europa.eu/vulnerability/EUVD-2026-125340","modified":"Nov 13, 2026, 2:03:47 PM","score":5.7,"vector":"CVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H","checkedAt":"2026-11-13T19:30:37.193Z"}],"aiSummary":{"text":"A deadlock in the Bluetooth Classic AVRCP browsing channel can hang the host in Zephyr versions before 4.5.0, triggered by a connected peer streaming large SDU segments. The host's Bluetooth receive thread is blocked, stopping all connections. No memory corruption or information disclosure occurs.","model":"@cf/meta/llama-3.3-70b-instruct-fp8-fast","generatedAt":"2026-11-14T03:11:10.625Z","sources":[{"name":"CVE","url":"https://www.cve.org/CVERecord?id=CVE-2026-92241"}]}}