CVE-2026-80819 in Linux
요약
\~에 의해 VulDB • 2026. 09. 04.
리눅스 커널에서 다음 취약점이 해결되었습니다:
블루투스: RFCOMM: 지연된 설정 수신을 위해 rfcomm_mutex 획득하기
rfcomm_sock_recvmsg()는 RFCOMM 잠금을 보유하지 않은 채로 rfcomm_dlc_accept()를 호출하여 지연된 설정을 완료합니다.
if (test_and_clear_bit(RFCOMM_DEFER_SETUP, &d->flags)) {
rfcomm_dlc_accept(d); return 0; }
그리고 rfcomm_dlc_accept()는 첫 번째 줄에서 세션을 역참조(deferences)합니다:
struct sock *sk = d->session->sock->sk;
d->session에 접근하는 다른 모든 경로는 rfcomm_mutex 하에서 실행됩니다. 여기에는 rfcomm_dlc_open(), rfcomm_dlc_close(), rfcomm_dlc_exists(), rfcomm_dlc_send_rpn()이 포함되며, RFCOMM 스레드도 rfcomm_process_sessions()를 통해 해당 잠금을 사용합니다. rfcomm_connect_ind()는 심지어 "rfcomm_lock() 하에서 호출됨"으로 문서화되어 있습니다. 이 호출 사이트가 이를 건너뛰는 유일한 사례입니다.
RFCOMM_DEFER_SETUP 비트는 __rfcomm_dlc_close()가 test_and_clear를 획득하면 조기에 반환하므로 수신이 종료(teardown)와 직렬화(serialises)되는 것처럼 보입니다. 그러나 rfcomm_recv_disc()은 먼저 상태를 강제로 변경합니다:
d->state = BT_CLOSED; __rfcomm_dlc_close(d, err);
조기 반환(BT_CONNECT, BT_CONFIG, BT_OPEN 및 BT_CONNECT2의 경우만 해당)은 이미 BT_CLOSED 상태인 경우에는 일치하지 않으므로, 해당 비트는 전혀 참조되지 않고 __rfcomm_dlc_close()가 rfcomm_dlc_unlink()으로 진행되어 d->session = NULL을 설정합니다.
따라서 지연된 DLC(dlc)에 대한 원격 DISC(Disconnect) 명령은 RFCOMM_DEFER_SETUP를 설정한 채로 세션을 지웁니다. 그 다음 recvmsg() 호출은 test_and_clear를 통과하고 NULL인 세역을 역참조하게 됩니다. 타이밍 윈도우(timing window)는 필요하지 않습니다. DISC가 처리된 후, 이 역참조는 조건 없이(unconditional) 발생합니다.
rfcomm_dlc_accept()에 rfcomm_dlc_open() 및 rfcomm_dlc_close()와 동일한 구조를 부여합니다: 두 내부(in-core) 호출자(이미 mutex를 보유함)가 계속 사용하는 __rfcomm_dlc_accept() 주위에 rfcomm_mutex를 획득하고 세션을 다시 확인하는 내보낸 래퍼(wrapper)입니다.
/dev/vhci를 통해 에뮬레이션된 BR/EDR 피어에서 KASAN + PROVE_LOCKING 커널로 재현되었습니다: 피어가 ACL 링크를 활성화하고 RFCOMM PSM에서 L2CAP를 열고, 세션을 시작하며, BT_DEFER_SETUP와 바인딩된 채널에 DLC를 연 후 소켓이 수락된 후에 DISC를 보냅니다. 수락된 소켓에서의 recv()는 다음과 같은 오류를 발생시킵니다:
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은 struct rfcomm_session에서 sock의 오프셋입니다. 이 패치를 적용하면 동일한 실행이 recv()가 0을 반환하고 보고 없이 완료되며, lockdep도 조용히 유지됩니다. 이는 해당 경로에서 스레드 측과 마찬가지로 lock_sock 전에 rfcomm_mutex가 여전히 획득됨을 확인해 줍니다.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.