CVE-2026-92241zephyrproject zephyr vulnerability
CVE-2026-92241 is a vulnerability in zephyrproject zephyr, rated medium (5.7 on CVSS 3.1).
Why this priority: Medium severity, with no exploitation signal.
Published · Updated · NVD status: Awaiting Analysis
What it is
The record does not classify the weakness yet; the description below says what the reporter found.
How it is reached
An attacker can exploit it from the same local network segment, with an ordinary user account, and nobody has to click anything.
What an attacker gains
A successful attack can take it offline.
Is it being exploited?
There is no public report of exploitation yet.
What to do
- Upgrade zephyrproject zephyr to 4.5.0 or later.
- Segment the networks that can reach it.
Description from NVD
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.
What this means for your architecture.
A CVE names a product. Whether it matters depends on where that product sits in your systems: what reaches it, which trust boundary it guards and what it can reach once compromised. Veriom maps your components, their relationships and your trust boundaries from your code, cloud and delivery evidence, so you can see where a component like this sits. The radar itself does not look at your systems.
Components it touches
- zephyrproject zephyr. Start from where it runs and what it is connected to.
Trust boundaries in play
- Local network segment. The attacker must share a network segment with the target.
Questions to answer about your own systems
- Where does zephyrproject zephyr run in your systems, and at which version?
- Which network segments can reach them?
- What can it reach once compromised: which data stores, secrets and services?
Sources
- CVE records and CVSS scores from the NVD CVE API. This product uses the NVD API but is not endorsed or certified by the NVD.
- Exploitation status from CISA’s Known Exploited Vulnerabilities catalog.
- Exploit likelihood from FIRST’s Exploit Prediction Scoring System (EPSS), refreshed daily.
- Explanations are written by Veriom from fixed templates over each record’s data, not by a person reviewing each CVE. Descriptions are quoted from the records as published.