Zephyr RTOS
CVE-2026-77684
MEDIUM
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessAuthenticate as Bluetooth Audio Gateway peer
-
DeliveryEstablish HFP session, send unsolicited +BCS
-
ExploitRFCOMM DISC strands queued AT+BCS buffer
-
ExecutionRepeat cycle to exhaust hf_pool
-
PersistFinal +BCS parks RX thread in K_FOREVER alloc
-
ImpactDevice hangs until reboot
Vulnerability Assessment
| Weakness |
CWE
ASVS 5.0
V15 - Secure Coding and Architecture Resource cleanup, leak prevention
|
| Exploitation Conditions | Requires a Zephyr build with CONFIG_BT_HFP_HF enabled (Bluetooth Classic Hands-Free Profile HF role). The attacker must be the remote Audio Gateway peer on an established HFP session; for SSP devices, L2CAP enforces authentication before the RFCOMM channel is reachable, so an authenticated/paired session is a prerequisite (PR:L). No user or local application interaction is needed (UI:N) - the unsolicited '+BCS' response plus RFCOMM DISC is attacker-driven end to end. Limiting factors: Bluetooth-adjacent range only (AV:A), the authenticated-session requirement, and the narrow HFP-HF build configuration; impact is limited to denial of service (device hang until reboot), with no confidentiality or integrity effect. |
| Impact | This is a genuine but bounded availability issue, not a top-tier emergency. The CVSS 3.1 vector (AV:A/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H, base 5.7) is internally consistent with the description: exploitation is over a Bluetooth-adjacent link (AV:A), requires low complexity (AC:L), and needs an established - and for SSP devices L2CAP-authenticated - HFP session (PR:L), with impact confined to availability (A:H only; C:N/I:N matches the CWE-401 memory-leak/resource-exhaustion nature). No EPSS score, KEV listing, or POC was provided in the input, so there is no public exploit identified at time of analysis and no evidence of active exploitation. The real risk is tempered by three factors: the attacker must already be the connected Audio Gateway peer on an authenticated session, the target must be built with CONFIG_BT_HFP_HF enabled, and the worst outcome is a device hang requiring reboot rather than code execution or data exposure. One data-quality conflict is worth flagging: the input Tags include 'Information Disclosure,' which contradicts the CVSS impact vector (C:N) and CWE-401 - this is a denial-of-service/resource-leak flaw, not an information-disclosure one. Priority should be moderate: patch on affected HFP-HF builds, but this is not a drop-everything internet-facing bug. |
| Exploit ScenarioDerived | An attacker within Bluetooth range who can establish (and, for SSP devices, authenticate) an HFP connection acts as the Audio Gateway and sends an unsolicited '+BCS: 1' codec response, causing the HF to queue an AT+BCS buffer that cannot be sent while RX is ongoing, then immediately issues an RFCOMM DISC to strand that buffer. Repeating the connect/+BCS/disconnect cycle a few times permanently drains the two-buffer hf_pool, after which one more +BCS parks the Bluetooth RX thread forever inside a K_FOREVER allocation, halting all HCI event processing until reboot. No public exploit code is identified at time of analysis, but the trigger is fully attacker-controlled and needs no user or application interaction. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 19, 2026
Denial of service in the Zephyr RTOS Bluetooth Classic Hands-Free Profile (HF role) allows a remote Audio Gateway peer to permanently leak entries from the fixed HFP TX buffer pool and then deadlock the Bluetooth RX thread, hanging the device until reboot. The bug lives in subsys/bluetooth/host/classic/hfp_hf.c: hfp_hf_disconnected() cancels work items and clears hf->acl but never drains the AT-command buffers queued on hf->tx_pending, and it leaves BT_HFP_HF_FLAG_CONNECTED set, while hfp_hf_create() memsets a reused HF slot without checking whether any work item is still pending or running. Only builds with CONFIG_BT_HFP_HF enabled are affected, and the attacker must reach an established, authenticated HFP session (paired/SSP devices have L2CAP authentication enforced before the RFCOMM channel is reachable), so this is an adjacent-range, authenticated-session availability issue rather than a drive-by one. No public exploit code was identified at time of analysis and the issue is not confirmed actively exploited (CISA KEV), but the per-cycle leak is trivially repeatable by any connected AG.
RemediationAI
Upstream fix available (PR/commit); released patched version not independently confirmed - apply Zephyr commit 59c947c71f3d9ab4cf10fd28846e6ca4a3d53819, or the corresponding backport in a maintained Zephyr release branch listed in advisory GHSA-hc6x-8gm2-2r9v, which clears BT_HFP_HF_FLAG_CONNECTED on disconnect, drains hf->tx_pending with net_buf_unref() so buffers return to hf_pool, and prevents reuse of an HF slot while hf->work, hf->slc_work or hf->deferred_work is still busy. If the fix cannot be deployed immediately, the strongest control is to drop CONFIG_BT_HFP_HF from the build when the Hands-Free role is not a shipping requirement - this removes the vulnerable code entirely at the cost of losing HFP HF functionality; where HFP is needed, require authenticated/paired AGs (SSP pairing with L2CAP authentication) and restrict which peers may bond, since the attacker must complete an HFP session to trigger the cycle, accepting the residual risk of a trusted-but-malicious or compromised AG. Raising CONFIG_BT_MAX_CONN to enlarge the pool buys additional leak cycles but does not stop the leak and should be treated only as a stopgap. A watchdog that resets the SoC when the Bluetooth RX thread stalls, and avoiding auto-reconnect to untrusted AGs, will reduce the duration of any successful hang but not the underlying bug.
Affects your stack
Find out whether the stacks and servers you run are on an affected version.
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
The flaw is a classic CWE-401 missing-release-of-memory defect in Zephyr's Bluetooth Classic HFP HF implementation, whose TX path is built on net_buf objects drawn from a small fixed pool (CONFIG_BT_MAX_CONN + 1 buffers, i.e. only two in the default configuration) and staged on the k_fifo hf->tx_pending before being handed to the RFCOMM DLC. When the peer AG sends an unsolicited "+BCS: 1" codec response, bcs_handle() calls bt_hfp_hf_select_codec() and queues an AT+BCS buffer; if BT_HFP_HF_FLAG_RX_ONGOING is set the buffer cannot be transmitted, and an RFCOMM DISC arriving immediately afterwards tears down the DLC without any code path ever dequeuing hf->tx_pending - hfp_hf_disconnected() only cancels work and clears hf->acl, and hfp_hf_create() later memset()s the slot, dropping the FIFO contents on the floor. Each cycle therefore permanently removes buffers from hf_pool. Once the pool is exhausted, bt_hfp_hf_send_cmd() calls bt_rfcomm_create_pdu() → bt_conn_create_pdu() with K_FOREVER from Bluetooth RX context, where that timeout is not downgraded to K_NO_WAIT, so a further "+BCS" parks the RX thread inside net_buf_alloc() with no possible waker and all HCI event processing stops until reboot. A second, independent defect is the object-lifetime race: because the disconnect path leaves BT_HFP_HF_FLAG_CONNECTED set and does not wait for running handlers, a reused HF slot could be wiped by memset() while hf->work, hf->slc_work or hf->deferred_work was still queued or executing on the system workqueue, corrupting shared k_work state. The upstream fix addresses both halves - it clears BT_HFP_HF_FLAG_CONNECTED before draining hf->tx_pending with k_fifo_get(K_NO_WAIT)/net_buf_unref (which also unblocks any sender stuck in the K_FOREVER allocation), and it makes hfp_hf_create() refuse to reuse a slot while k_work_busy_get()/k_work_delayable_busy_get() report pending or running work, returning NULL so the caller retries later.
Know when Bluetooth gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
AV:A/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Bluetooth-adjacent (AV:A), low complexity (AC:L), requires an authenticated HFP/RFCOMM session so PR:L; availability-only impact (A:H) as the stack hangs until reboot, no data exposure.
Primary rating from Vendor (zephyr).
CVSS VectorVendor: zephyr
DescriptionCVE.org
The Bluetooth Classic Hands-Free Profile HF role in subsys/bluetooth/host/classic/hfp_hf.c does not release the AT command buffers that are still queued on hf->tx_pending when the RFCOMM DLC goes down. hfp_hf_disconnected() only cancelled the work items and cleared hf->acl, and no other code path ever dequeues those buffers, so each one is permanently lost from the fixed hf_pool (CONFIG_BT_MAX_CONN + 1 buffers, i.e. two in the default configuration). The same function also left BT_HFP_HF_FLAG_CONNECTED set, and hfp_hf_create() wiped the object with memset() as soon as hf->acl was NULL, without checking whether hf->work, hf->slc_work or hf->deferred_work was still pending or running.
The remote Audio Gateway peer controls the trigger end to end and needs no application involvement: an unsolicited +BCS: 1 response makes bcs_handle() call bt_hfp_hf_select_codec() and queue an AT+BCS buffer, which cannot be transmitted while BT_HFP_HF_FLAG_RX_ONGOING is set, and an immediately following RFCOMM DISC strands that buffer. Repeating the connect / +BCS / disconnect cycle a couple of times empties hf_pool for good.
With the pool exhausted, HFP command sending fails permanently, and because hfp_hf_send_cmd() allocates with K_FOREVER (bt_rfcomm_create_pdu() → bt_conn_create_pdu()) from the Bluetooth RX context - where that timeout is not downgraded to K_NO_WAIT - one further +BCS from the peer parks the Bluetooth RX thread inside net_buf_alloc() with no possible waker, halting all HCI event processing until the device is rebooted. Separately, reusing the HF slot while a work handler was still queued or running allowed memset() to wipe live k_work items out from under the system workqueue, corrupting shared kernel workqueue state. Exploitation requires an established HFP session (for SSP devices L2CAP enforces authentication before the RFCOMM channel is reachable) and a build with CONFIG_BT_HFP_HF enabled.
Threat Intelligence Overview
NVD
CVE.org
EPSS
GitHub
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Affected Products (CPE)CVE.org
Unauthenticated Bluetooth Low Energy OTA firmware upgrade in the Meatmeet Pro WiFi & Bluetooth Meat Thermometer firmware
CVE-2025-32879 is a security vulnerability (CVSS 8.8) that allows an attacker. Risk factors: public PoC available.
Zephyr's Bluetooth Low Energy connection-response handler fails to verify that a connection request was actually initiat
Heap OOB write in Android Bluetooth driver via incorrect bounds check.
A use-after-free in the Android Bluetooth stack (bluetooth_ccc.cc, function BluetoothCccHandlerCallbackImpl) lets an att
Legacy pairing and secure-connections pairing authentication in Bluetooth BR/EDR Core Specification v5.2 and earlier may
Memory corruption in the Zephyr RTOS LE Audio Broadcast Sink (subsys/bluetooth/audio/bap_broadcast_sink.c) lets an attac
A memory leak combined with a use-after-free in the Linux kernel's Bluetooth HCI connection-setup path can crash the ker
A race condition in the Linux kernel's Bluetooth L2CAP subsystem allows a use-after-free of the hci_conn::l2cap_data poi
Bluetooth authentication bypass in SwitchBot Door Lock Series allows an attacker within BLE range to manipulate the lock
Out-of-bounds read in the Linux kernel Bluetooth subsystem's eir_get_service_data() leaks kernel heap memory into usersp
Use-after-free in the Linux kernel Bluetooth L2CAP stack lets a Bluetooth-adjacent attacker corrupt kernel memory by rac
Exploit-DB