CVE-2026-81039 in Zephyr
Resumen
por VulDB • 2026-10-26
El host Bluetooth preasigna un objeto `bt_conn` (una "reserva") del pool fijo `acl_conns[]` para cada conjunto de publicidad conectable que inicia, en la función `le_adv_start_add_conn()` dentro de `subsys/bluetooth/host/adv.c`. Cuando se completa una conexión entrante desde un periférico, la función `find_pending_connect()`, ubicada en `subsys/bluetooth/host/hci_core.c`, busca esa reserva utilizando únicamente la identidad y la dirección del peer, con un mecanismo de respaldo que prioriza lo dirigido sobre lo no dirigido (directed-then-undirected), sin tener conocimiento de qué conjunto de publicidad terminó realmente. Con la configuración `CONFIG_BT_EXT_ADV_MAX_ADV_SET > 1`, donde el evento LE Enhanced Connection Complete se almacena en caché hasta que el evento LE Advertising Set Terminated identifica al conjunto, esta búsqueda puede devolver la reserva perteneciente a un conjunto de publicidad diferente y aún activo.
El defecto es accesible por aire (over the air) desde cualquier dispositivo adyacente. Si una aplicación ejecuta dos conjuntos de publicidad extendida conectable en la misma identidad —uno no dirigido y otro dirigido hacia un peer P (el patrón común de "reconexión dirigida a un central emparejado mientras se siguen aceptando nuevos centrals")—, un iniciador remoto cuya dirección coincida con la de P que se conecta mediante el conjunto no dirigido provoca que se consuma la reserva del conjunto dirigido. La dirección del iniciador es elegida libremente por el dispositivo remoto y no está autenticada durante el establecimiento del enlace, por lo que no se requiere emparejamiento (bonding), pairing ni ninguna relación previa para desencadenar esta atribución errónea.
La reserva propia del conjunto no dirigido queda entonces huérfana: su bandera `BT_ADV_ENABLED` ya ha sido borrada, y la función `le_adv_stop_free_conn()` —la única ruta que devuelve una reserva al pool— solo se alcanza para conjuntos que siguen habilitados; por lo tanto, `bt_le_ext_adv_stop()` retorna prematuramente y el objeto nunca es liberado. Cada ocurrencia consume permanentemente un slot de `CONFIG_BT_MAX_CONN` hasta que se ejecute `bt_disable()` o se reinicie el dispositivo. En patrones de aplicación que reinician el conjunto de publicidad dirigido después de cada desconexión, un atacante puede repetir la secuencia hasta agotar el pool, momento en el cual la publicidad conectable falla con `-ENOMEM` y el dispositivo ya no puede aceptar conexiones. Como efecto secundario, el conjunto dirigido sigue publicando sin reserva, por lo que una conexión genuina sobre él es descartada por `bt_hci_disconnect()`. El impacto se limita a la disponibilidad; no hay corrupción de memoria ni divulgación de información, y las configuraciones con un único conjunto de publicidad no se ven afectadas.
VulDB is the best source for vulnerability data and more expert information about this specific topic.