{"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 \u2014 through l2cap_br_alloc_frag() and net_buf_append_bytes() \u2014 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 \u2014 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"}}}}

{}

{"affected": [{"affectedData": [{"collectionURL": "https://github.com/zephyrproject-rtos/zephyr", "defaultStatus": "unaffected", "packageName": "zephyr", "product": "zephyr", "programFiles": ["subsys/bluetooth/host/classic/avrcp.c"], "programRoutines": [{"name": "browsing_avrcp_l2cap_alloc_buf"}], "vendor": "zephyrproject", "versions": [{"lessThan": "4.5.0", "status": "affected", "version": "4.4.0", "versionType": "semver"}]}], "source": "[email protected]"}], "cveTags": [], "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 \u2014 through l2cap_br_alloc_frag() and net_buf_append_bytes() \u2014 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 \u2014 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."}], "id": "CVE-2026-92241", "lastModified": "2026-11-13T14:18:03.763", "metrics": {"cvssMetricV31": [{"cvssData": {"attackComplexity": "LOW", "attackVector": "ADJACENT_NETWORK", "availabilityImpact": "HIGH", "baseScore": 5.7, "baseSeverity": "MEDIUM", "confidentialityImpact": "NONE", "integrityImpact": "NONE", "privilegesRequired": "LOW", "scope": "UNCHANGED", "userInteraction": "NONE", "vectorString": "CVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H", "version": "3.1"}, "exploitabilityScore": 2.1, "impactScore": 3.6, "source": "[email protected]", "type": "Secondary"}]}, "published": "2026-11-13T14:18:01.850", "references": [{"source": "[email protected]", "url": "https://github.com/zephyrproject-rtos/zephyr/commit/c8c2438f05165397347613b44dd8e9eaa1243139"}, {"source": "[email protected]", "url": "https://github.com/zephyrproject-rtos/zephyr/security/advisories/GHSA-8vpg-4235-9qjj"}], "sourceIdentifier": "[email protected]", "vulnStatus": "Awaiting Analysis", "weaknesses": [{"description": [{"lang": "en", "value": "CWE-833"}], "source": "[email protected]", "type": "Secondary"}]}

{}

{}