Files
vuln-cve/data/2026/92xxx/CVE-2026-92241.json
T

93 lines
5.3 KiB
JSON

{
"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"
}
}
}
}