CVE-2026-80819 in Linux
Zusammenfassung
von VulDB • 04.09.2026
Im Linux-Kernel wurde folgende Schwachstelle behoben:
Bluetooth: RFCOMM: rfcomm_mutex für die verzögerte Setup-Annahme verwenden
rfcomm_sock_recvmsg() schließt ein verzögertes Setup ab, indem es rfcomm_dlc_accept() aufruft, ohne eine RFCOMM-Sperre zu halten:
if (test_and_clear_bit(RFCOMM_DEFER_SETUP, &d->flags)) {
rfcomm_dlc_accept(d); return 0; }
und rfcomm_dlc_accept() dereferenziert die Sitzung in der ersten Zeile:
struct sock *sk = d->session->sock->sk;
Jeder andere Pfad, der auf d->session zugreift, wird unter rfcomm_mutex ausgeführt: rfcomm_dlc_open(), rfcomm_dlc_close(), rfcomm_dlc_exists(), rfcomm_dlc_send_rpn() und der RFCOMM-Thread über rfcomm_process_sessions(). rfcomm_connect_ind() ist sogar als „aufgerufen unter rfcomm_lock()" dokumentiert. Diese Aufrufstelle ist die einzige, die dies überspringt.
Das RFCOMM_DEFER_SETUP-Bit scheint den Accept gegen das Herunterfahren zu serialisieren, da __rfcomm_dlc_close() frühzeitig zurückkehrt, wenn es test_and_clear gewinnt. Aber rfcomm_recv_disc() erzwingt zuerst den Status:
d->state = BT_CLOSED; __rfcomm_dlc_close(d, err);
und die frühe Rückgabe deckt nur BT_CONNECT, BT_CONFIG, BT_OPEN und BT_CONNECT2 ab. Mit dem bereits eingestellten Zustand BT_CLOSED stimmt dieser Switch nicht überein, das Bit wird niemals konsultiert, und __rfcomm_dlc_close() fällt durch zu rfcomm_dlc_unlink(), was d->session = NULL setzt.
Ein Remote-DISC auf einem verzögerten DLC löscht also die Sitzung, während RFCOMM_DEFER_SETUP gesetzt bleibt. Der nächste recvmsg()-Aufruf führt dann den test_and_clear aus und dereferenziert eine NULL-Sitzung. Es ist kein Timing-Fenster erforderlich: Sobald das DISC verarbeitet wurde, ist die Dereferenzierung bedingungslos.
Geben Sie rfcomm_dlc_accept() dieselbe Struktur wie rfcomm_dlc_open() und rfcomm_dlc_close(): einen exportierten Wrapper, der rfcomm_mutex übernimmt und die Sitzung erneut überprüft, umgeben von einem __rfcomm_dlc_accept(), das von den beiden internen Aufrufern verwendet wird, die die Mutex bereits halten.
Reproduziert auf einem KASAN + PROVE_LOCKING-Kernel mit einem über /dev/vhci emulierten BR/EDR-Peer: Der Peer baut eine ACL-Verbindung auf, öffnet L2CAP am RFCOMM-PSM, startet eine Sitzung, öffnet ein DLC an einem Kanal, der mit BT_DEFER_SETUP gebunden ist, und sendet DISC nach dem Akzeptieren des Sockets. recv() auf dem akzeptierten Socket trifft dann auf:
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 ist der Offset von sock in struct rfcomm_session. Mit diesem Patch wird derselbe Lauf mit recv() abgeschlossen, das 0 zurückgibt und keine Meldung ausgibt, und lockdep bleibt ruhig, was bestätigt, dass rfcomm_mutex auf diesem Pfad vor lock_sock übernommen wird, wie es auch auf der Thread-Seite der Fall ist.
If you want to get best quality of vulnerability data, you may have to visit VulDB.