---
id: "CVE-2026-92241"
page: "https://infrastack.ai/live/CVE-2026-92241"
kind: "vulnerability"
aliases: ["CVE-2026-92241"]
title: "Zephyr Bluetooth: paired AVRCP peer can hang the whole Bluetooth host"
severity: "medium"
cvss: 5.7
epss: null
exploited: false
status: "open"
category: "runtime"
products: []
ecosystems: []
tags: ["avrcp", "bluetooth", "embedded", "runtime", "zephyr"]
not_affected_if: ["ble-only", "default-config", "no-avrcp-browsing", "unpaired-peers"]
published_at: "2026-11-13T14:18:01+00:00"
first_seen_at: "2026-11-13T15:19:50+00:00"
updated_at: "2026-11-13T15:21:31+00:00"
sources: [{"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-92241", "first_seen_at": "2026-11-13T15:19:50+00:00"}]
exploit_sources: []
---

# Zephyr Bluetooth: paired AVRCP peer can hang the whole Bluetooth host

Link for people: https://infrastack.ai/live/CVE-2026-92241 (this .md is for agents)

A paired Bluetooth Classic peer that opens the AVRCP browsing channel and streams segmented L2CAP data can exhaust a receive-buffer pool and block the Bluetooth RX thread forever. The result is a permanent hang of all Bluetooth host processing on the device until reboot, with no code execution or data exposure reported.

_Summary, check and fix written by a model from the sources; labelled as such._

## How to check

- Check whether the build sets `CONFIG_BT_CLASSIC` and the experimental `CONFIG_BT_AVRCP_BROWSING` option
- Check whether the application registers AVRCP callbacks
- Check the Zephyr version in use against the fix, since the sources give no fixed version

## Timeline

- 2026-11-13T15:19:50+00:00 nvd https://nvd.nist.gov/vuln/detail/CVE-2026-92241

## Documents

- [advisory] Vendor advisory: github.com https://github.com/zephyrproject-rtos/zephyr/security/advisories/GHSA-8vpg-4235-9qjj
- [fix] Patch: github.com https://github.com/zephyrproject-rtos/zephyr/commit/c8c2438f05165397347613b44dd8e9eaa1243139

## From the sources

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.

The 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.

Triggering 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.

The 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.

---

_Free to read, with fair use of about 60 pages a minute. For higher limits or API access: sales@infrastack.ai_