Zephyr 经典蓝牙 AVRCP 浏览通道死锁 CVE-2026-92241 已在 4.5.0 修复

昨天翻 Zephyr 项目 11 月 13 日刚发的安全通告 GHSA-8vpg-4235-9qjj，第一反应是又一个普通的蓝牙栈 bug，往下读完发现这个死锁的触发条件干净得吓人：不需要任何畸形报文，几百字节完全合规的分段 L2CAP 流量就能把整台设备的蓝牙主机线程永久挂死，只能重启恢复。







漏洞编号 CVE-2026-92241，CVSS v3.1 基分 5.7（AV:A/AC/PR/UI:N/S:U/C:N/I:N/A:H），官方定级 Moderate，CWE-833 死锁。我顺手查了 NVD 的 API，这条记录 2026-11-13T14:18 发布，状态还是 Awaiting Analysis，评分直接沿用 CNA（Zephyr 项目方）提供的 5.7，NVD 自己的分析还没做，目前只有一个口径。



机理我用两份来源核对过：Zephyr 官方安全通告（GitHub Security Advisory）和 Tenable 的 CVE 页，两边描述逐句一致，版本范围、评分、修复 commit 也对得上。漏洞出在经典蓝牙 AVRCP 浏览通道的接收缓冲回调上。subsys/bluetooth/host/classic/avrcp.c 里的 browsing_avrcp_l2cap_alloc_buf() 用 K_FOREVER 从共享的 avctp_browsing_rx_pool 里分配缓冲，而这个回调是在蓝牙接收工作线程 bt_workq 里被 L2CAP 调用的——对每个新 SDU 的头缓冲调用一次，重组 SDU 时经 l2cap_br_alloc_frag() 和 net_buf_append_bytes() 对每个后续分段还要再调一次。麻烦在于，释放这些缓冲的也是同一个线程：bt_l2cap_br_recv_seg() 交付完整 SDU 之后调 net_buf_unref() 才会释放。自己阻塞着等自己释放，这个等待永远等不到。



缓冲池的容量也小：默认配置下就是 CONFIG_BT_MAX_CONN + 1 个缓冲，每个 CONFIG_BT_AVRCP_BROWSING_L2CAP_MTU 字节，默认是 2 个 339 字节的缓冲。而 bt_l2cap_br_recv_seg() 在 subsys/bluetooth/host/classic/l2cap_br.c 里接受 SAR_START 段里对端声明的 SDU 长度，没有用 br_chan->rx.mtu 去收口，对端只要声明一个很大的 SDU 再持续发后续分段，就能一个分段吃掉一个池缓冲，几下抽干。下一笔分配就在回调里永久阻塞。挂死的还不只是 AVRCP：被阻塞的 bt_workq 负责整个 bt_dev.rx_queue 的 HCI ACL 数据和低优先级事件，还跑主机内部的工作项，所以所有蓝牙连接全部停摆，状态不可恢复，只能重启。没有内存破坏，没有信息泄露，是纯粹的可用性击穿。



触发门槛要数清楚。固件得开了 CONFIG_BT_CLASSIC 和还是实验选项的 CONFIG_BT_AVRCP_BROWSING，应用注册了 AVRCP 回调，然后对端要建立 AVRCP 控制通道、再建浏览通道——浏览通道要求已配对的加密链路。满足这些条件之后，攻击流量本身就是普通流量。这类配置组合在跑经典蓝牙的嵌入式设备上不算冷门，凡固件基于 4.4.x 且开了浏览通道的都落在受影响范围里。



受影响版本是 4.4.0 及以上、4.5.0 以下，官方修复在 4.5.0，改法是把分配从 K_FOREVER 换成 K_NO_WAIT，池子空了就返回 local-busy 或直接断开通道，应用层可以恢复。v4.4 分支的回补 PR #119991 已经合并，main 线的修复是 PR #118673，commit c8c2438f05165397347613b44dd8e9eaa1243139。通告里还标了引入点：commit 497d3bb（Bluetooth: AVRCP: Add alloc_buf callback and browsing RX pool，2025-11-18）加上了这个浏览 RX 池和 K_FOREVER 分配，也就是说这个问题在 4.4 线里存在了近一年才披露。



有一点我没敢写死：官方通告里写的是 release lines that have not yet taken the backport remain affected，也就是除了已回补的 4.4 分支，其他还没吃到修复的旧版本线按通告口径仍然受影响，但通告没有逐条列出版本线的回补状态，我手上也没有逐版本线的清单，这里按通告原文表述，不替官方推定。



处置上给我自己的清单：跑 Zephyr 且开了经典蓝牙的固件，先查版本，4.5.0 以下直接升级；暂时升不了的，把 CONFIG_BT_AVRCP_BROWSING 关掉是最干净的止血，它本来就还是实验选项；关不了浏览通道的场景，至少把浏览通道建立时的配对审计开起来，陌生设备发起的浏览通道建立要留痕。漏洞报告渠道也顺手记一下：vulnerabilities@lists.zephyrproject.org（Zephyr 官方通告末尾给的地址）。



K_FOREVER 在工作线程上下文里做阻塞分配这个坑不止 Zephyr 踩过，这次又是释放者自己堵在同一个等待上的经典死锁形态。写下来留个底。



来源列表（查阅日期 2026-11-14）：

1. Zephyr Project 官方安全通告 GHSA-8vpg-4235-9qjj，2026-11-13 发布：https://github.com/zephyrproject-rtos/zephyr/security/advisories/GHSA-8vpg-4235-9qjj

2. NVD 官方 API CVE-2026-92241 记录（published 2026-11-13T14:18，Awaiting Analysis，CVSS 3.1 5.7 由 CNA 提供）：https://services.nvd.nist.gov/rest/json/cves/2.0?cveId=CVE-2026-92241

3. Tenable CVE-2026-92241 页（机理与版本范围与官方通告一致）：https://www.tenable.com/cve/CVE-2026-92241

4. 修复 commit c8c2438f05165397347613b44dd8e9eaa1243139：https://github.com/zephyrproject-rtos/zephyr/commit/c8c2438f05165397347613b44dd8e9eaa1243139

5. 引入 commit 497d3bb：https://github.com/zephyrproject-rtos/zephyr/commit/497d3bba43eb6f4bd115b3593daf5f8dafb83ae7



交叉验证说明：机理描述、受影响范围（4.4.0 及以上、4.5.0 以下）、修复版本 4.5.0、CVSS 3.1 基分 5.7 及向量、CWE-833 由 GitHub 官方通告（一手）与 Tenable 页（二手）逐项核对一致；NVD API 为独立第三源，其评分与官方通告一致。



HKTULU

2026-11-14