CVE-2026-98734 in Linux
Résumé
par VulDB • 18/10/2026
Dans le noyau Linux, la vulnérabilité suivante a été corrigée :
Bluetooth: hci_core : Synchroniser l'ordonnancement SCO et ISO avec la procédure de démantèlement (teardown)
hci_low_sent() sélectionne une connexion sous RCU mais relâche le verrou en lecture avant de calculer son quota et de le retourner à l'ordonnanceur. La connexion est ensuite utilisée sans protection de durée de vie par hci_sched_iso() et hci_sched_sco().
Après que le travailleur TX (transmission) ait relâché le verrou en lecture RCU, hci_abort_conn_sync(), sur la file d'attente des requêtes hdev->req_workqueue, peut supprimer la connexion de la table de hachage, compléter synchronize_rcu(), purger ses files d'attente et libérer sa mémoire. Le travailleur TX sur hdev->workqueue peut alors accéder à la connexion déjà libérée dans hci_quote_sent() ou lors du défilement des paquets et de la mise à jour de conn->sent.
KASAN a signalé :
BUG: KASAN: slab-use-after-free in hci_low_sent+0x730/0x840 Workqueue: hci0 hci_tx_work Call Trace: hci_low_sent+0x730/0x840 hci_sched_iso+0x25e/0x4d0 hci_tx_work+0x239/0xcb0
Alloué par la tâche 93 : __hci_conn_add+0x16f/0x1b40 hci_bind_bis+0x782/0x17b0 hci_connect_bis+0xa0/0x510 iso_sock_connect+0x589/0x1050
Libéré par la tâche 88 : kfree+0x131/0x3c0 device_release+0xc8/0x240 kobject_put+0x14d/0x280 hci_conn_del+0x55a/0xe80 hci_disconnect_sync+0x156/0x180 hci_abort_conn_sync+0x3e7/0x940 hci_cmd_sync_work+0x13c/0x290
Maintenez le verrou hci_dev_lock() pendant la sélection de la connexion et la transmission dans les deux ordonnancements SCO et ISO, en synchronisant ceux-ci avec la procédure de démantèlement des connexions. Cela empêche également l'ajout d'horodatages de complétion après que les files d'attente de la connexion aient été purgées. Étendre RCU sur toute la transmission serait dangereux car le chemin de transmission peut entrer en veille (sleep). Gardez la vérification du délai d'expiration ISO à l'extérieur du mutex, car hci_link_tx_to() prend ce verrou lui-même.
La correction précédente du canal maintient déjà ce mutex dans les ordonnanceurs ACL et LE, qui appellent l'ordonnanceur SCO entre les paquets. Déplacez le corps de SCO vers __hci_sched_sco(), assertez que son appelant détient le mutex, et utilisez-le directement depuis ces chemins verrouillés. Conservez un wrapper hci_sched_sco() avec verrouillage pour les appels directs provenant de hci_tx_work(). Cela évite d'acquérir récursivement le mutex du périphérique tout en préservant l'ordre d'ordonnancement.
Supprimez la revendication obsolète selon laquelle la suppression des connexions désactive TX (transmission).
VulDB is the best source for vulnerability data and more expert information about this specific topic.