CVE-2026-77684
El rol HF del perfil Bluetooth Classic Hands-Free (HFP) en subsys/bluetooth/host/classic/hfp_hf.c no libera los búferes de comandos AT que siguen encolados en hf->tx_pending cuando el DLC de RFCOMM se cae. hfp_hf_disconnected() solo cancelaba los elementos de trabajo y ponía a NULL hf->acl, y ningún otro camino de ejecución vuelve a extraer esos búferes, de modo que cada uno se pierde de forma permanente del hf_pool de tamaño fijo (CONFIG_BT_MAX_CONN + 1 búferes, es decir, dos en la configuración por defecto). Esa misma función también dejaba activo BT_HFP_HF_FLAG_CONNECTED, y hfp_hf_create() ponía a cero el objeto con memset() en cuanto hf->acl era NULL, sin comprobar si hf->work, hf->slc_work o hf->deferred_work seguían pendientes o en ejecución.
Leer descripción completaMostrar menos
El par remoto, la Audio Gateway, controla el desencadenante de principio a fin y no necesita intervención de la aplicación: una respuesta no solicitada +BCS: 1 hace que bcs_handle() llame a bt_hfp_hf_select_codec() y encole un búfer AT+BCS, que no puede transmitirse mientras BT_HFP_HF_FLAG_RX_ONGOING esté activo, y un DISC de RFCOMM que llegue inmediatamente después deja ese búfer atascado. Repetir el ciclo de conexión / +BCS / desconexión un par de veces vacía hf_pool de forma definitiva.
Con el pool agotado, el envío de comandos HFP falla de forma permanente. Como hfp_hf_send_cmd() reserva memoria con K_FOREVER (bt_rfcomm_create_pdu() → bt_conn_create_pdu()) desde el contexto de RX de Bluetooth, donde ese tiempo de espera no se rebaja a K_NO_WAIT, un +BCS adicional del par bloquea el hilo de RX de Bluetooth dentro de net_buf_alloc() sin ningún posible desbloqueo, deteniendo todo el procesamiento de eventos HCI hasta que se reinicie el dispositivo. Por otra parte, reutilizar la ranura HF mientras un manejador de trabajo seguía encolado o en ejecución permitía que memset() borrara elementos k_work activos del workqueue del sistema, corrompiendo el estado compartido del workqueue del kernel. La explotación requiere una sesión HFP establecida (en dispositivos SSP, L2CAP exige autenticación antes de que el canal RFCOMM sea accesible) y una compilación con CONFIG_BT_HFP_HF habilitado.
Traducción automática del texto original de NVD (en inglés).
CVSS
- Puntuación base
- 5.7
- Versión
- 3.1
- Vector
- CVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Probabilidad de explotación (EPSS)
- Probabilidad de explotación en los próximos 30 días
- 0.21 %
- Percentil entre todas las CVEs puntuadas
- 10
- Fecha de la puntuación
- 20/10/2026
EPSS (Exploit Prediction Scoring System, de FIRST) estima la probabilidad de que una vulnerabilidad sea explotada en 30 días. Complementa a CVSS (impacto) y a CISA KEV (explotación confirmada).
Técnicas ATT&CK
Cómo se explota esta vulnerabilidad y qué consigue el atacante, en el lenguaje de MITRE ATT&CK.
- Explotación
T1210Exploitation of Remote Serviceslateral movement85 % - Impacto principal
T1499Endpoint Denial of Serviceimpact90 %
Vector AV:A/PR:L/UI:N indica red adyacente, así que T1210 según la regla; el texto describe el bloqueo del hilo RX y de HCI tras agotar hf_pool (A:H).
Inferido por nuestro agente de análisis a partir de la descripción oficial, el vector CVSS y la CWE, y comprobado por un supervisor. Puede contener errores.
Mitigaciones ATT&CK que cubren estas técnicas
Tecnologías afectadas (1)
⚠ Inferidas por IA a partir de la descripción — NVD aún no ha analizado esta CVE; no son CPE verificados.
CWE
- CWE-401
Referencias
JSON original (NVD)
Mostrar
{
"id": "CVE-2026-77684",
"cveTags": [],
"metrics": {
"cvssMetricV31": [
{
"type": "Secondary",
"source": "vulnerabilities@zephyrproject.org",
"cvssData": {
"scope": "UNCHANGED",
"version": "3.1",
"baseScore": 5.7,
"attackVector": "ADJACENT_NETWORK",
"baseSeverity": "MEDIUM",
"vectorString": "CVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"integrityImpact": "NONE",
"userInteraction": "NONE",
"attackComplexity": "LOW",
"availabilityImpact": "HIGH",
"privilegesRequired": "LOW",
"confidentialityImpact": "NONE"
},
"impactScore": 3.6,
"exploitabilityScore": 2.1
}
]
},
"affected": [
{
"source": "vulnerabilities@zephyrproject.org",
"affectedData": [
{
"vendor": "zephyrproject",
"product": "zephyr",
"versions": [
{
"status": "affected",
"version": "4.2.0",
"versionType": "semver",
"lessThanOrEqual": "4.4.2"
}
],
"packageName": "zephyr",
"programFiles": [
"subsys/bluetooth/host/classic/hfp_hf.c"
],
"collectionURL": "https://github.com/zephyrproject-rtos/zephyr",
"defaultStatus": "unaffected",
"programRoutines": [
{
"name": "hfp_hf_create"
},
{
"name": "hfp_hf_disconnected"
},
{
"name": "hfp_hf_send_cmd"
}
]
}
]
}
],
"published": "2026-10-19T23:17:37.197",
"references": [
{
"url": "https://github.com/zephyrproject-rtos/zephyr/commit/59c947c71f3d9ab4cf10fd28846e6ca4a3d53819",
"source": "vulnerabilities@zephyrproject.org"
},
{
"url": "https://github.com/zephyrproject-rtos/zephyr/security/advisories/GHSA-hc6x-8gm2-2r9v",
"source": "vulnerabilities@zephyrproject.org"
}
],
"vulnStatus": "Received",
"weaknesses": [
{
"type": "Secondary",
"source": "vulnerabilities@zephyrproject.org",
"description": [
{
"lang": "en",
"value": "CWE-401"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "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.\n\nThe 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.\n\nWith 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."
}
],
"lastModified": "2026-10-19T23:17:37.197",
"sourceIdentifier": "vulnerabilities@zephyrproject.org"
}