CVE-2026-80819 in Linux
Résumé
par VulDB • 04/09/2026
Dans le noyau Linux, la vulnérabilité suivante a été corrigée :
Bluetooth: RFCOMM: acquérir rfcomm_mutex pour l'acceptation de configuration différée
rfcomm_sock_recvmsg() finalise une configuration différée en appelant rfcomm_dlc_accept() sans détenir aucun verrou RFCOMM :
if (test_and_clear_bit(RFCOMM_DEFER_SETUP, &d->flags)) {
rfcomm_dlc_accept(d); return 0; }
et rfcomm_dlc_accept() désérialise la session dès sa première ligne :
struct sock *sk = d->session->sock->sk;
Chaque autre chemin qui accède à d->session s'exécute sous le verrou rfcomm_mutex : rfcomm_dlc_open(), rfcomm_dlc_close(), rfcomm_dlc_exists(), rfcomm_dlc_send_rpn(), et le thread RFCOMM via rfcomm_process_sessions(). rfcomm_connect_ind() est même documenté comme étant « appelé sous rfcomm_lock() ». Ce point d'appel est le seul à l'omettre.
Le bit RFCOMM_DEFER_SETUP semble sérialiser l'acceptation par rapport au démontage, car __rfcomm_dlc_close() retourne prématurément lorsqu'il remporte la comparaison test_and_clear. Mais rfcomm_recv_disc() force d'abord l'état :
d->state = BT_CLOSED; __rfcomm_dlc_close(d, err);
et le retour anticipé ne couvre que les états BT_CONNECT, BT_CONFIG, BT_OPEN et BT_CONNECT2. Avec un état déjà défini à BT_CLOSED, cette instruction switch ne correspond pas, le bit n'est jamais consulté, et __rfcomm_dlc_close() continue son exécution jusqu'à rfcomm_dlc_unlink(), qui définit d->session = NULL.
Ainsi, une commande DISC distante sur un DLC (Data Link Connection) différé efface la session tout en laissant RFCOMM_DEFER_SETUP défini. L'appel suivant à recvmsg() passe le test_and_clear et désérialise une session nulle. Aucune fenêtre de concurrence temporelle n'est nécessaire : une fois que le DISC a été traité, la désérialisation est inconditionnelle.
Donnez à rfcomm_dlc_accept() la même structure qu'à rfcomm_dlc_open() et rfcomm_dlc_close() : un wrapper exporté qui acquiert rfcomm_mutex et revérifie la session, autour d'un __rfcomm_dlc_accept() que les deux appelants internes (qui détiennent déjà le mutex) continuent d'utiliser.
Reproduit sur un noyau KASAN + PROVE_LOCKING avec un pair BR/EDR émulé via /dev/vhci : le pair établit une liaison ACL, ouvre L2CAP sur le PSM RFCOMM, démarre une session, ouvre un DLC sur un canal lié avec BT_DEFER_SETUP, et envoie DISC après que la socket a été acceptée. Un appel à recv() sur la socket acceptée déclenche alors :
Oops: general protection fault KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017]
RIP: 0010:rfcomm_dlc_accept+0x54/0x350 Call Trace: rfcomm_sock_recvmsg+0x1cd/0x230 sock_recvmsg+0x166/0x1c0 __sys_recvfrom+0x20d/0x300
La valeur 0x10 correspond au décalage de sock dans la structure rfcomm_session. Avec ce correctif, l'exécution identique se termine avec recv() retournant 0 et aucun rapport d'erreur, et lockdep reste silencieux, confirmant que rfcomm_mutex est bien acquis avant lock_sock sur ce chemin, comme c'est le cas du côté thread.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.