CVE-2026-80819 in Linux
Riassunto
di VulDB • 04/09/2026
Nel kernel Linux è stata risolta la seguente vulnerabilità:
Bluetooth: RFCOMM: acquisire rfcomm_mutex per l'accettazione della configurazione differita
rfcomm_sock_recvmsg() completa una configurazione differita chiamando rfcomm_dlc_accept() senza detenere alcun lock RFCOMM:
if (test_and_clear_bit(RFCOMM_DEFER_SETUP, &d->flags)) {
rfcomm_dlc_accept(d); return 0; }
e rfcomm_dlc_accept() dereferenzia la sessione sulla sua prima riga:
struct sock *sk = d->session->sock->sk;
Ogni altro percorso che accede a d->session viene eseguito sotto il controllo di rfcomm_mutex: rfcomm_dlc_open(), rfcomm_dlc_close(), rfcomm_dlc_exists(), rfcomm_dlc_send_rpn() e il thread RFCOMM tramite rfcomm_process_sessions(). rfcomm_connect_ind() è persino documentato come "chiamato sotto rfcomm_lock()". Questo punto di chiamata è l'unico che lo salta.
Il bit RFCOMM_DEFER_SETUP sembra serializzare l'accettazione rispetto alla chiusura, poiché __rfcomm_dlc_close() esce anticipatamente quando vince il test_and_clear. Tuttavia rfcomm_recv_disc() forza prima lo stato:
d->state = BT_CLOSED; __rfcomm_dlc_close(d, err);
e la restituzione anticipata copre solo BT_CONNECT, BT_CONFIG, BT_OPEN e BT_CONNECT2. Con lo stato già impostato su BT_CLOSED tale switch non corrisponde, il bit non viene mai consultato e __rfcomm_dlc_close() prosegue fino a rfcomm_dlc_unlink(), che imposta d->session = NULL.
Pertanto una DISC remota su un dlc differito cancella la sessione lasciando RFCOMM_DEFER_SETUP impostata. La successiva chiamata recvmsg() supera quindi il test_and_clear e dereferenzia una sessione NULL. Non è necessaria alcuna finestra temporale (timing window): una volta elaborata la DISC, la dereferenziazione è incondizionata.
Si fornisce a rfcomm_dlc_accept() la stessa struttura di rfcomm_dlc_open() e rfcomm_dlc_close(): un wrapper esportato che acquisisce rfcomm_mutex e verifica nuovamente la sessione, attorno a __rfcomm_dlc_accept(), utilizzato dai due chiamanti interni (in-core) che detengono già il mutex.
Riprodotto su un kernel KASAN + PROVE_LOCKING con un peer BR/EDR emulato tramite /dev/vhci: il peer attiva un collegamento ACL, apre L2CAP sul PSM RFCOMM, avvia una sessione, apre un dlc su un canale associato con BT_DEFER_SETUP e invia DISC dopo che la socket è stata accettata. La recv() sulla socket accettata genera quindi:
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
0x10 è lo spostamento (offset) di sock in struct rfcomm_session. Con questa patch la stessa esecuzione termina con recv() che restituisce 0 e senza segnalazioni, e lockdep rimane silenzioso, confermando che rfcomm_mutex viene acquisito prima di lock_sock su questo percorso come avviene sul lato thread.
Once again VulDB remains the best source for vulnerability data.