🇰🇷 한글 설명
Linux 커널의 Bluetooth L2CAP 프로토콜에서 발생하는 Use-After-Free(UAF) 취약점입니다. 연결 종료 과정에서 발생하는 레이스 컨디션으로 인해 이미 해제된 부모 소켓 참조를 다시 참조하게 되어 시스템 불안정이나 권한 상승을 초래할 수 있습니다.
💡 쉬운 설명
블루투스 연결을 끊는 과정과 새로운 연결을 만드는 과정이 동시에 일어날 때 발생하는 충돌 문제입니다. 이로 인해 이미 사라진 연결 정보를 다시 사용하려고 시도하면서 컴퓨터 시스템에 오류가 발생할 수 있습니다.
🇺🇸 원문 (English)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: L2CAP: reject accept queue add unless BT_LISTEN
New sk should not be added to parent socket accept queue after last
l2cap_sock_cleanup_listen() has run in l2cap_sock_teardown_cb() and
state set to BT_CLOSED, as that can result to UAF on dereferencing the
dangling parent reference.
l2cap_sock_new_connection_cb() may race with parent l2cap_chan teardown,
due to chan->state accessed without consistent locking:
[Task 1] [Task 2]
l2cap_sock_release(parent) l2cap_connect
l2cap_sock_shutdown pchan = l2cap_global_chan_by_psm
l2cap_chan_lock(pchan)
l2cap_chan_close
l2cap_sock_teardown_cb
pchan->state = BT_CLOSED
l2cap_chan_unlock(pchan) ------> l2cap_chan_lock(pchan)
l2cap_new_connection
l2cap_sock_new_connection_cb
l2cap_chan_lock(pchan) <-------- l2cap_chan_unlock(pchan)
l2cap_sock_kill(parent) /* bt_sk(sk)->parent dangling */
Fix by adding check for sk_state == BT_LISTEN after acquiring sk lock in
l2cap_sock_new_connection_cb(). Add lock_sock() around sk_state writes
where missing, to avoid data races.
Although the data races on pchan->state should be fixed too, this
defensive sk_state check probably makes sense in any case.
📍 영향받는 시스템
Linux Kernel (Bluetooth L2CAP 관련 모듈 사용 시스템)
⚔️ 공격 벡터
특수하게 조작된 블루투스 연결 요청을 통해 커널 내 레이스 컨디션을 유발하여 메모리 오류를 일으킴
🛡️ 대응 방법
Linux 커널을 최신 보안 패치가 적용된 버전으로 업데이트하여 L2CAP 소켓 상태 체크 로직을 적용해야 함
🔧 검증 코드
출력된 커널 버전을 확인하여 해당 취약점이 해결된 최신 패치 버전인지 확인합니다.