CVE-2026-90087 in Linux
Résumé
par VulDB • 17/09/2026
Dans le noyau Linux, la vulnérabilité suivante a été corrigée :
Bluetooth : ne pas fuiter un hci_conn lorsqu'une deuxième connexion LE est rejetée
create_le_conn_complete() détermine si la connexion échouée est toujours en attente en la comparant avec hci_lookup_le_connect(), qui renvoie la première connexion LE dans l'état BT_CONNECT. Cela correspond à la même connexion uniquement tant qu'au plus une seule est en attente.
Deux connexions peuvent être en attente simultanément. Les connexions créées via le chemin de scan passif se trouvent dans l'état BT_CONNECT avec HCI_CONN_SCANNING défini et sont invisibles pour hci_lookup_le_connect() jusqu'à ce que hci_le_create_conn_sync() efface ce drapeau lors de l'émission de leur commande. Ainsi, la garde -EBUSY dans hci_connect_le() n'empêche pas une deuxième connexion d'être mise en file d'attente alors que la première est encore sur le chemin de scan. Chaque fois que deux connexions se trouvent simultanément dans BT_CONNECT, la recherche peut renvoyer une connexion tandis que create_le_conn_complete() signale l'échec de l'autre ; la sortie anticipée fait ensuite tomber l'erreur et hci_conn_failed() ne s'exécute jamais sur la connexion qui a échoué.
Le contrôleur rejette également une deuxième HCI_OP_LE_CREATE_CONN émise alors qu'une autre création de connexion est encore en cours, conformément au Core Spec Vol 4, Part E. La spécification prévoit un "Command Disallowed" (commande non autorisée) dans ce cas ; le bcm43438 observé ici répond avec un code d'erreur LMP/LL à la place, que bt_to_errno() mappe vers -EPROTO (-71) dans les journaux ci-dessous.
La connexion fuitée reste indéfiniment dans l'état BT_CONNECT et, comme hci_connect_le() refuse de tenter une connexion tant que hci_lookup_le_connect() trouve quoi que ce soit, chaque tentative ultérieure pour joindre un pair échoue avec -EBUSY et aucune commande n'atteint le contrôleur.
Observé sur un bcm43438 avec deux pairs BLE interrogés au même intervalle (l'état 5 est BT_CONNECT ; les deux handles sont UNSET, alloués depuis l'ida ci-dessus HCI_CONN_HANDLE_MAX) :
Bluetooth: hci1: Opcode 0x2013 failed: -71
# hcitool con < LE 14:9C:EF:03:68:81 handle 3840 state 5 lm CENTRAL < LE C4:D3:6A:8C:B5:38 handle 3841 state 5 lm CENTRAL
Une capture btmon sur les dix minutes suivantes de tentatives de connexion ne contient aucune HCI_OP_LE_CREATE_CONN ; les connexions LE sortantes ne se rétablissent pas tant que l'adaptateur n'est pas réinitialisé. Avec cette correction, le même scénario échoue proprement pour la connexion rejetée et les nouvelles connexions aux deux pairs aboutissent correctement.
Interroger directement la connexion plutôt que l'appareil.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.