'GhostLock'(CVE-2026-43499): 15년 묵은 리눅스 커널 rtmutex 버그가 root와 컨테이너를 함께 내준 이유

리눅스 커널의 rtmutex(real-time mutex)는 스레드 간 우선순위 역전을 막기 위한 priority
inheritance 로직을 담고 있는, 십수 년 넘게 손댈 일이 거의 없던 오래된 락(lock) 서브시스템입니다.
그런데 2026년 7월, 바로 이 코드에서 2011년 커널 2.6.39 시절부터 존재해 온 use-after-free
취약점이 공개됐습니다. 로그인만 되어 있으면 별도 권한이나 특수한 설정 없이 일반 스레딩 API 호출만으로
root 권한을 딸 수 있고, 컨테이너 격리까지 그대로 뚫립니다. 연구팀이 붙인 이름은 ‘GhostLock’
(CVE-2026-43499)이고, 공개된 익스플로잇은 재현율이 97%에 달합니다. 이 글에서는 GhostLock의
기술적 원인, 익스플로잇 체인, 영향 범위와 패치 현황을 정리합니다.

Contents:

GhostLock(CVE-2026-43499)이란

GhostLock은 리눅스 커널 rtmutex의 priority inheritance 정리(cleanup) 경로에서 발생하는
use-after-free 취약점입니다. 취약한 코드는 2011년 커널 2.6.39에서 처음 만들어져 약 15년간
주요 배포판 전반에 기본으로 포함되어 있었습니다. 보안 연구팀 Nebula가 이를 무기화해 커널 메모리
유출부터 임의 읽기/쓰기, 제어 흐름 탈취, 최종 root 권한 획득까지 이어지는 완전한 익스플로잇 체인을
완성했고, 구글 kernelCTF 버그 바운티로 92,337달러를 받았습니다. 공격에는 네트워크 접근이나
특수 capability가 필요 없고, 로컬에서 실행되는 일반 스레드 프로그램만으로 충분하며, 공개된 PoC는
약 5초 안에 root 셸을 띄웁니다.

기술적 원인 — remove_waiter()의 포인터 혼동

버그의 핵심은 rtmutex의 remove_waiter() 정리 경로에 있습니다. 이 함수는 futex
대기 중이던 스레드를 우선순위 상속 체인에서 제거할 때, 실제로 대기하고 있던(waiter) 태스크가
아니라 현재 실행 중인(currently executing) 태스크를 기준으로 포인터를 지우는 로직 오류를
갖고 있습니다. 그 결과 이미 해제된 커널 스택 메모리를 계속 가리키는 댕글링 포인터(dangling
pointer)가 남습니다.

Nebula의 공개 분석에 따르면 공격자는 세 개의 futex와 여러 개의 스레드를 조합해 의도적으로
우선순위 역전(priority inversion) 데드락 상황을 만든 뒤, 해제된 스택 프레임을 위조된
waiter 구조체로 다시 채워 넣습니다(heap/stack spraying과 유사한 재점유 기법). 이렇게 확보한
제한적 쓰기(constrained write) 권한을 커널 임의 읽기/쓰기로 확장하고, 최종적으로 제어 흐름을
탈취해 root 권한 셸을 얻는 방식입니다. 경쟁 조건 자체는 정교한 타이밍 조작이 필요하지만, 일단
성립하면 재현율이 매우 높다는 것이 특징입니다.

IonStack 익스플로잇 체인과 컨테이너 탈출

GhostLock은 단독으로도 로컬 권한상승 버그지만, Nebula가 ‘IonStack’이라 부르는 더 큰 체인의
뒷부분이기도 합니다. 체인의 앞부분은 브라우저 안에서 코드를 실행시키고 샌드박스를 탈출하는
Firefox 취약점(CVE-2026-10702)이고, GhostLock이 그 뒤를 이어받아 샌드박스 탈출 수준의
권한을 커널 root까지 끌어올립니다. 즉 웹 페이지 방문만으로 시작해 root까지 도달하는 전체
공격 경로가 성립할 수 있다는 뜻입니다.

더 눈여겨볼 부분은 컨테이너 탈출입니다. GhostLock은 애플리케이션 레이어가 아니라 호스트
커널 자체의 버그이기 때문에, 컨테이너 안에서 실행되는 프로세스라도 커널을 공유하는 이상 똑같이
이 취약점을 트리거할 수 있습니다. 즉 네임스페이스나 cgroup 격리는 GhostLock 앞에서 별다른
방어 수단이 되지 못하며, 침해당한 컨테이너 하나가 호스트 전체를 장악하는 발판이 될 수 있습니다.

영향 범위와 패치 타임라인

취약한 코드 범위는 2011년 커널 2.6.39부터 수정 커밋이 반영되기 직전 버전까지입니다. 상류
(upstream) 수정은 커밋 3bfdc63936dd로 리눅스 7.1에 병합됐습니다. 각 배포판은
이를 별도 브랜치에 백포트하는 방식으로 패치를 배포하는데, 예를 들어 AlmaLinux는 8/9/10 계열별로
각각 kernel-4.18.0-553.141.2.el8_10, kernel-5.14.0-687.24.1.el9_8,
kernel-6.12.0-211.32.1.el10_2 이상 버전에서 수정됐습니다. RHEL은 6부터 10까지 전 버전과
레이어드 제품 전반이 영향을 받는다고 확인했고, Ubuntu는 7월 8일 기준 24.04/22.04/20.04 LTS가
여전히 취약 또는 패치 진행 중으로 CVE 트래커에 표시되어 있었습니다(USN-8488-1,
USN-8489-1, USN-8507-1 등 관련 보안 공지 참고). CloudLinux 계열은 재부팅 없이 적용
가능한 KernelCare 라이브패치도 제공하고 있습니다.

현재까지 실제 공격에 악용된 사례는 보고되지 않았지만, 익스플로잇 코드가 이미 공개되어 있고
재현율도 높은 편이라 ‘악용까지 시간 문제’로 보는 시각이 많습니다.

주의사항

PoC가 이미 공개돼 있고 재현율도 높으므로, 서버·데스크톱·컨테이너 호스트 구분 없이 커널 업데이트를 최우선 순위로 적용해야 합니다.
커널 버전 숫자만으로는 패치 여부를 확신할 수 없습니다. 배포판마다 보안 패치를 별도 브랜치에 백포트하므로, 실제로는 벤더의 CVE 공지나 패키지 변경 로그로 확인해야 합니다.
컨테이너 격리는 GhostLock에 대한 방어 수단이 되지 못하므로, “컨테이너라서 안전하다”는 가정은 통하지 않습니다. 호스트 커널 패치가 곧 컨테이너 보안입니다.

uname -r
apt changelog linux-image-$(uname -r) 2>/dev/null | grep -i '43499\|GhostLock'
rpm -q --changelog kernel 2>/dev/null | grep -i '43499\|GhostLock'

위 명령은 각각 Debian/Ubuntu 계열과 RHEL 계열에서 설치된 커널 패키지의 변경 로그에 CVE-2026-43499 관련 수정이 포함됐는지 확인하는 용도입니다. 아무 결과도 나오지 않으면 아직 패치가 반영되지 않았을 가능성이 높으므로 배포판 보안 공지를 다시 확인해야 합니다.

마무리

GhostLock은 15년 가까이 아무도 들여다보지 않았던 rtmutex priority inheritance 코드에서
나온 버그라는 점에서, “오래되고 안정적인 코드는 안전하다”는 통념이 얼마나 위험한 가정인지를
보여줍니다. 게다가 브라우저 샌드박스 탈출과 엮인 IonStack 체인, 그리고 커널을 공유하는 이상
무력화되는 컨테이너 격리까지 감안하면, 영향 범위를 로컬 서버 한 대로 좁혀 생각할 문제가
아닙니다. 아직 패치를 적용하지 않은 시스템이 있다면 커널 업데이트부터 확인하는 것이 우선입니다.