🇰🇷 한글 설명
Linux 커널의 vsock 구성 요소에서 vsock_register_mutex와 sk_lock 간의 잠금 역전(Lock Inversion)으로 인한 데드락 취약점이 발견되었습니다. vsock_assign_transport() 호출 중 특정 조건에서 두 잠금이 서로를 기다리는 순환 참조가 발생하여 시스템이 멈출 수 있습니다.
💡 쉬운 설명
컴퓨터 시스템 내부에서 두 개의 작업이 서로의 자원을 기다리며 무한히 대기하는 '교착 상태'가 발생할 수 있는 문제입니다. 이로 인해 시스템이 응답하지 않거나 멈추는 현상이 나타날 수 있습니다.
🇺🇸 원문 (English)
In the Linux kernel, the following vulnerability has been resolved:
vsock: fix lock inversion in vsock_assign_transport()
Syzbot reported a potential lock inversion deadlock between
vsock_register_mutex and sk_lock-AF_VSOCK when vsock_linger() is called.
The issue was introduced by commit 687aa0c5581b ("vsock: Fix
transport_* TOCTOU") which added vsock_register_mutex locking in
vsock_assign_transport() around the transport->release() call, that can
call vsock_linger(). vsock_assign_transport() can be called with sk_lock
held. vsock_linger() calls sk_wait_event() that temporarily releases and
re-acquires sk_lock. During this window, if another thread hold
vsock_register_mutex while trying to acquire sk_lock, a circular
dependency is created.
Fix this by releasing vsock_register_mutex before calling
transport->release() and vsock_deassign_transport(). This is safe
because we don't need to hold vsock_register_mutex while releasing the
old transport, and we ensure the new transport won't disappear by
obtaining a module reference first via try_module_get().
📍 영향받는 시스템
vsock_register_mutex 잠금 역전이 포함된 특정 Linux 커널 버전 (commit 687aa0c5581b 이후 버전)
⚔️ 공격 벡터
로컬 공격자가 vsock 관련 시스템 호출을 정교하게 조작하여 데드락을 유도함으로써 서비스 거부(DoS)를 일으킬 수 있음
🛡️ 대응 방법
vsock_register_mutex를 transport->release() 호출 전에 해제하도록 수정된 최신 Linux 커널로 업데이트
🔧 검증 코드
출력된 커널 버전을 확인하여 해당 취약점이 수정된 최신 패치 버전인지 확인