CVE-2026-99009 in Linux
Résumé
par VulDB • 23/10/2026
Dans le noyau Linux, la vulnérabilité suivante a été corrigée :
Bluetooth: RFCOMM - connexion du socket de session sans rfcomm_mutex
Un appel à connect() dans RFCOMM émis pendant l'authentification d'un lien BR/EDR provoque un rapport de dépendance circulaire par lockdep, et le cycle signalé correspond à une véritable condition de concurrence AB/BA entre rfcomm_mutex et hdev->lock.
rfcomm_security_cfm() est appelé depuis la voie des événements HCI, qui détient déjà hdev->lock :
hci_rx_work() hci_event_packet() hci_cc_read_enc_key_size() [hdev->lock]
hci_encrypt_cfm() [hci_cb_list_lock]
rfcomm_security_cfm() [rfcomm_mutex]
tandis qu'un appel à connect() dans RFCOMM provenant de l'espace utilisateur prend les deux mêmes verrous dans l'ordre inverse :
rfcomm_sock_connect() rfcomm_dlc_open() [rfcomm_mutex]
__rfcomm_dlc_open() rfcomm_session_create() kernel_connect() l2cap_sock_connect() l2cap_chan_connect() [hdev->lock]
AVERTISSEMENT : possible dépendance de verrouillage circulaire détectée kworker/u131:1/1128 essaie d'acquérir le verrou : rfcomm_mutex, à : rfcomm_security_cfm+0x31/0x3e0 [rfcomm]
mais la tâche détient déjà ce verrou : hci_cb_list_lock, à : hci_cc_read_enc_key_size+0x1d2/0xcc0 La chaîne existe de : rfcomm_mutex --> &hdev->lock --> hci_cb_list_lock
hci_auth_complete_evt() et hci_encrypt_change_evt() atteignent le callback de la même manière.
Les deux ordres doivent être observés lors du même démarrage, c'est pourquoi une simple connexion BR/EDR ne suffit pas pour l'afficher : une session configurée par le côté distant est créée par rfcomm_accept_connection() dans krfcommd, qui appelle kernel_accept() et ne prend jamais hdev->lock sous rfcomm_mutex. La connexion d'un appareil qui authentifie et chiffre le lien, puis l'appel à connect() sur un socket RFCOMM vers n'importe quelle adresse - la connexion doit réussir, l'ordre est enregistré avant le délai de page - signale ce problème à chaque fois.
Seul le socket de session doit être connecté avec le verrou détenu, et il ne l'est pas : rien d'autre ne peut voir le socket avant qu'il ne soit ajouté à la liste des sessions. Connectez-le donc en premier, puis acquérez rfcomm_mutex par la suite, ce qui supprime définitivement l'ordre rfcomm_mutex -> hdev->lock, plutôt que de maintenir la voie des événements HCI hors de rfcomm_mutex.
rfcomm_session_create() devient rfcomm_session_connect(), qui renvoie le socket connecté sans toucher à la liste des sessions, et rfcomm_dlc_open() ajoute la session une fois qu'il détient à nouveau le verrou. Si un autre appelant a ajouté une session pour la même paire pendant que ce socket se connectait, cette session est utilisée et ce socket est abandonné. __rfcomm_dlc_open() prend désormais la session qu'il doit utiliser, et sa vérification d'état s'exécute après la réacquisition du verrou, de sorte qu'un DLC ouvert ou fermé dans l'intervalle est toujours géré correctement.
Sur un lien ACL existant, la connexion peut se terminer avant que la session n'atteigne la liste, et le réveil issu du callback du socket est alors perdu ; krfcommd est donc réveillé une fois que la session devient visible.
La connexion sans verrou ouvre une fenêtre dans laquelle le socket peut être fermé. Le DLC ne faisant pas encore partie d'une session, rfcomm_dlc_close() ne trouve rien à faire et retourne sans y toucher, tandis que rfcomm_dlc_open()) attacherait alors un DLC dont le propriétaire a disparu. rfcomm_dlc_close() marque désormais ce type de DLC avec RFCOMM_CLOSED, et rfcomm_dlc_open() vérifie cette marque une fois qu'il détient à nouveau rfcomm_mutex, abandonnant le socket au lieu d'attacher le DLC. La marque est effacée lorsqu'une ouverture commence, afin qu'un DLC réutilisé ne soit pas affecté. Cela couvre les deux appelants de rfcomm_dlc_open(), le socket et la couche tty.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.