GhostLock, 15년 전 Futex의 취약점을 루트 셸로 전환

요약

전체 버전으로 이동 ↓

이것이 무엇인지: GhostLock(CVE-2026-43499)은 리눅스 커널의 futex 우선순위 상속 코드에서 발생하는 ‘use-after-free’ 취약점으로, 이는 glibc의 PTHREAD_PRIO_INHERIT 뮤텍스. 정리 단계에서 잘못된 스레드의 관리 정보를 지워버리면, 이미 해제된 메모리를 가리키는 활성 스레드가 남게 됩니다. 특이하게도, 그 메모리는 커널에 위치해 있습니다. 스택, 대부분의 이런 버그가 발생하는 힙이 아니라. 전체 버전으로 이동 →

영향: 로컬 권한 상승을 통해 루트 권한 획득. 네뷸라 시큐리티(Nebula Security)가 공개한 풀 체인 익스플로잇은 비특권 프로세스에서 약 5초 만에 약 97%의 성공률로 루트 권한을 획득합니다. 저희는 데비안 11/12/13, EL7 및 EL10 환경에서 트리거 및 로컬 DoS 현상을 재현했습니다. 영향을 받는 커널은 단순히 DoS에 취약한 것뿐만 아니라 루트 권한을 악용당할 수 있다고 가정해야 합니다. 자세한 내용 보기 →

위험도: CVSS 7.8 (높음). 로컬 벡터, 낮은 복잡도, 사용자 상호작용 불필요, 지원 대상에서 매우 신뢰할 수 있는 공개 LPE 체인이 존재합니다. Red Hat은 이를 ‘중요’ 등급으로 평가합니다. 상세 내용으로 이동 →

누가 영향을 받나요: 유일한 전제 조건은 CONFIG_FUTEX_PI=y, 모든 주요 배포판에서 기본적으로 활성화되어 있으며, 특별한 기능, 네임스페이스 또는 하드웨어가 필요하지 않습니다. 리눅스 2.6.39-rc1(2011년 5월)에서 도입되었으며, 취약점이 있는 버전은 v7.1-rc1까지 이어지므로 거의 모든 운영 환경용 커널이 해당됩니다. 전체 버전으로 이동 →

관련 결함: 이에 따른 변경 사항으로, 74e144274af3 (CVE-2026-53166)는 이후 회귀 현상이 발생하여 업스트림에서 롤백되었습니다. CVE-2026-43499 및 주요 수정 사항을 통해 GhostLock의 적용 범위를 확인하십시오. 3bfdc63936dd. 전체 버전으로 이동 →

상태: 제로데이가 아니라 N-데이입니다. 4월 18일에 보고되었으며, 4월 20일에 업스트림에서 수정되었습니다 (3bfdc63936dd), 그리고 5월 4일에 역포트되었으며, 이 모든 조치는 7월 7일 공개되기 전에 이루어졌습니다. 작동하는 익스플로잇이 공개되었고, 이 취약점은 이미 보안 관련 언론에 보도된 상태입니다. 전체 버전으로 이동 →

지금 바로 조치하세요: 호스트 전체에 적용할 수 있는 깔끔한 런타임 완화책은 없습니다. 취약점이 있는 기능은 컴파일 시에 내장되어 있어, 실행 중인 커널에서는 비활성화할 수 없습니다. 공급업체에서 제공한 수정된 커널을 적용하거나 KernelCare의 재부팅 없이 적용 가능한 패치를 적용하세요. 컨테이너 환경에서는 futex PI 작업을 차단하는 seccomp 필터를 적용하면 취약점을 차단할 수 있지만, 해당 잠금을 사용하는 워크로드가 정상적으로 작동하지 않을 수 있습니다. 자세한 내용 보기 →

이 티켓을 낮은 우선순위로 등록하고 싶게 만드는 두 가지 이유가 있는데, 둘 다 잘못된 생각입니다.

첫 번째는 코드의 연식입니다. GhostLock은 2011년 5월에 출시된 잠금 루틴에 존재합니다. 15년 동안 조용히 잠복해 있던 이 버그는 마치 이론적인 호기심 대상처럼 보입니다. 학회 발표 주제로 선정될 법하지만 실제 운영 환경의 호스트에는 절대 영향을 미치지 않는 그런 종류의 발견이죠. 이러한 해석은 편하지만 틀린 것입니다. 이 버그는 기본 설정의 커널에서 권한이 없는 프로세스에서도 접근할 수 있으며, 이를 통해 단 몇 초 만에 루트 셸을 확보할 수 있는 공개된 풀 체인 익스플로잇이 존재합니다.

두 번째는 “futex”라는 용어입니다. futex(fast userspace mutex)는 glibc와 같은 라이브러리가 스레드 간 잠금을 구현하는 데 사용하는 커널의 기본 구성 요소입니다. 이는 대부분의 애플리케이션이 직접 다루지 않는 심오한 내부 구조처럼 들리는데, 실제로도 그렇습니다. 하지만 이 버그의 핵심인 ‘우선순위 상속 잠금(priority-inheritance locking)’ 기능은 결코 틈새 기능이 아닙니다. CONFIG_FUTEX_PI 모든 주요 배포판에서 기본적으로 활성화되어 있으며, glibc는 이를 사용하여 PTHREAD_PRIO_INHERIT 뮤텍스이며, 이 취약한 경로는 권한, 네임스페이스 또는 특수 하드웨어 없이도 접근할 수 있습니다. 사용 중인 커널이 해당 범위에 속하고 기본 구성으로 빌드된 경우, 이 취약점이 존재합니다.

GhostLock은 Nebula Security의 “IonStack” 연구 시리즈의 두 번째 사례로, 2026년 7월 7일 VEGA로 알려진 팀에 의해 공개되었으며, 전체 연구 보고서, 버그 목록 항목, 그리고 전체 체인을 아우르는 공개 개념 증명(PoC)이 함께 공개되었습니다. 이 취약점은 6월 30일 Google kernelCTF에서 92,337달러의 보상금을 받았습니다. 저희는 7월 8일 아침에 이 취약점을 파악했으며, KernelCare 엔지니어가 당일 바로 여러 배포판에 걸친 재현 작업을 시작했습니다.

자세한 내용을 살펴보기 전에 명심해야 할 점이 하나 있습니다. 이는 배포판 고유의 문제가 아니라 메인라인의 버그입니다. futex PI로 빌드된 2.6.39-rc1부터 7.1-rc1까지의 모든 커널에는 취약한 코드가 포함되어 있습니다. 공개된 익스플로잇은 마지막 단계에서 특정 대상에 한정되지만, 근본적인 결함은 거의 모든 버전에 적용됩니다.

GhostLock의 작동 원리

먼저 관련 커널 부분부터 살펴보겠습니다. 스레드가 우선순위 상속 잠금(priority-inheritance lock)에서 대기할 때, 커널은 ‘웨이터(waiter)’라고 하는 작은 레코드에 그 관계를 추적하며, 대기 중인 스레드가 어떤 잠금에 의해 차단되었는지( pi_blocked_on). 이러한 부기 기록을 올바르게 정리하는 것이 중요한데, 이는 스레드가 더 이상 존재하지 않는 잠금에 대해 여전히 ‘차단됨’ 상태로 표시된 채로 종료될 경우, 커널이 아무것도 가리키지 않는 포인터를 보유하게 되기 때문이다.

정리 루틴은, remove_waiter(),는 하나의 스레드가 자신의 대기 상태를 정리하는 단순한 경우를 위해 작성되었습니다. 이 코드는 커널이 current, 바로 대기 중이던 그 스레드입니다. ‘requeue-PI’라고 하는 더 고급 연산은 이러한 가정을 깨뜨립니다. requeue-PI는 대기 중인 스레드를 한 잠금에서 다른 잠금으로 이동시킵니다(이것이 조건 변수를 효율적으로 구현하는 방식입니다). 즉, 이동을 수행하는 것은 대기 중이던 스레드가 아니라 정리 작업을 실행 중인 스레드입니다.

여기에 오류가 있습니다. 커널이 재큐잉(requeue)을 수행하면 데드락(각 스레드가 다음 스레드를 기다리는 악순환)이 발생할 것이라고 감지하고 오류와 함께 중단할 때, 롤백 경로는 다음을 호출합니다. remove_waiter(), 그리고 remove_waiter() 지우다 current->pi_blocked_on, 그 이삿짐 레코드를 사용하며, 실제 웨이터의 레코드는 사용하지 않습니다. 대기 스레드는 절대 정리되지 않습니다. 사용자 공간으로 돌아올 때, 그 pi_blocked_on 여전히 자체 스택 프레임을 가리키고 있는데, 커널은 이미 그 공간을 다른 용도로 회수했습니다. 해제된 스택 메모리를 가리키는 이 매달린 포인터가 바로 ‘해제 후 사용(use-after-free)’ 오류입니다.

대략적으로 말하자면, 이 익스플로잇은 이를 바탕으로 다음과 같이 구성됩니다:

[Unprivileged process, three threads/futexes]
│  stage a deadlock cycle so the kernel takes the buggy rollback path
▼
[remove_waiter() clears the wrong thread's record → a live thread points into its own freed stack frame]
│
▼
[Reclaim that freed frame with attacker-controlled data → forge a fake waiter record]
│
▼
[Trigger the cleanup again → write one attacker-chosen pointer into a kernel network table]
│
▼
[Point that table entry at attacker code → send one IPv6 UDP packet to run it]
▼
[Flip a system setting (core_pattern) so a crash handler runs as root → root shell]

자세한 원리를 알고 싶은 독자들을 위해 설명하자면, 공격자는 세 개의 스레드와 futex를 사용하여 다음과 같은 방식으로 교착 상태를 유발합니다. FUTEX_LOCK_PI, FUTEX_WAIT_REQUEUE_PI, 그리고 FUTEX_CMP_REQUEUE_PI 운영으로 인해, 이는 -EDEADLK (교착 상태) 복귀와 버그가 있는 롤백. 그런 다음 다음을 사용하여 해제된 스택 프레임을 회수합니다. PR_SET_MM_MAP, 프로그램이 커널이 자체 스택으로 복사하는 필드를 설정할 수 있게 해주는 프로세스 제어 호출로, 해당 메모리를 위조된 rt_mutex_waiter 기록합니다. 그러면 커널의 웨이터 트리 정리 작업은 단일한 제어된 포인터 쓰기 작업으로 전환되며, 이는 inet6_protos[IPPROTO_UDP], 커널에 들어오는 IPv6 UDP 패킷을 처리할 함수를 알려주는 테이블 항목입니다. 공격자는 해당 항목을 고정되고 예측 가능한 주소(CPU 엔트리 영역, 즉 항상 알려진 위치에 존재하는 CPU별 영역)에 배치된 “피벗(pivot)” 명령어로 지정한 다음, 이를 호출하기 위해 IPv6 UDP 패킷을 전송합니다. 그러면 제어권이 리턴 지향 프로그래밍(ROP) 체인(기존 커널 코드 조각들을 연결하여 임의의 로직을 실행하는 방식)으로 넘어가며, 마지막 단계에서 해당 항목의 권한을 반전시킵니다. core_pattern 이 설정은 프로세스가 충돌할 때 어떤 프로그램이 실행될지 제어하므로, 공격자의 충돌 처리기가 루트 권한으로 실행됩니다.

관련된 함수는 다음과 같습니다. remove_waiter(), rt_mutex_start_proxy_lock(), 그리고 rt_mutex_adjust_prio_chain() 에서 kernel/locking/rtmutex.c. 이 버그 유형은 커널 스택의 ‘사용 후 해제(use-after-free)’ 결함으로, 로컬 권한 상승을 초래합니다. 여기서 ‘스택’이라는 용어에 주목할 필요가 있습니다. 악용 가능한 대부분의 ‘사용 후 해제’ 버그는 힙 객체를 손상시키는데, 힙의 레이아웃은 비교적 조작하기 쉽기 때문입니다. 해제된 특정 영역을 다시 확보하는 스택 콘텐츠가 제어되는 프레임은 구현하기 더 어렵고 흔하지도 않은데, 이것이 바로 이 버그가 흥미로울 뿐만 아니라 연구자의 손에서는 여전히 신뢰할 수 있는 이유 중 하나입니다.

‘Upstream Fix’의 변경 사항

주요 수정 사항은 한 줄의 코드 수정입니다. 패치 적용 전에는 데드락 롤백 시 잘못된 스레드의 차단 레코드가 지워졌습니다. 패치 적용 후에는, remove_waiter() 지우다 waiter->task->pi_blocked_on (진짜 웨이터의 기록)보다는 current->pi_blocked_on (이동자의), 따라서 언와인드 시에는 해제된 스택 메모리를 가리키는 활성 스레드가 더 이상 남지 않게 됩니다.

개념적으로:

Before:  deadlock rollback → clear the mover's record → real waiter left pointing at freed memory → use-after-free
After:   deadlock rollback → clear the real waiter's record → nothing left dangling

상류 커밋 내용은 다음과 같습니다. 3bfdc63936dd (“rtmutex: remove_waiter()에서 current 대신 waiter::task 사용”). 이에 따른 후속 변경 사항인 74e144274af3은 CVE-2026-53166으로 별도로 추적되었으나, 이후 회귀 현상이 발생하여 업스트림에서 되돌려졌습니다. 이 변경 사항은 GhostLock에 필요한 두 번째 수정 사항으로 간주되어서는 안 됩니다.

이는 데이터 구조 레이아웃에 어떠한 변경도 가하지 않는, 소규모의 독립적인 잠금 경로 변경이므로, 모든 커널 계열에 걸쳐 재부팅 없이 적용할 수 있는 깔끔한 패치 후보입니다.

누가 영향을 받나요?

GhostLock은 다음으로 빌드된 리눅스 시스템에 영향을 미칩니다. CONFIG_FUTEX_PI=y, 이는 모든 주요 배포판의 기본 설정입니다. 이 취약점이 있는 코드는 다음 커밋에서 도입되었습니다. 8161239a8bcc 리눅스 2.6.39-rc1(2011년 5월)에서 발견되었으며, 이 취약점이 적용되는 버전은 v7.1-rc1까지 이어집니다. 실제로는 사실상 모든 커널에 영향을 미칩니다. 즉, 해당 버전 범위 내에서 futex PI를 사용하여 빌드된 모든 커널이 취약합니다.

KernelCare 팀이 공개된 PoC를 사용하여 해당 취약점, 트리거 및 로컬 DoS 현상을 재현한 것이 확인되었습니다:

• 데비안 13 (현재 수정됨, 아래 참조)
• 데비안 12, 취약점이 발견되었으나 아직 수정되지 않음
• 데비안 11, 아직 에라타가 발표되지 않은 상태의 취약점 존재
• Enterprise Linux 7, DoS 재현
• Enterprise Linux 10, DoS 재현

전체 체인 루트 권한: 연구원은 약 97%의 신뢰도로 루트 권한을 공개적으로 시연했습니다. 무기화된 익스플로잇 구성 요소는 대상별로 특화되어 있으며, 소스 코드에 대상별 메모리 오프셋이 내장되어 있습니다. 저희의 다중 배포판 검증에서는 각 배포판에서 대상별 루트 권한이 아닌 트리거 및 use-after-free 취약점을 테스트했습니다. 안전한 가정으로는, 영향을 받는 커널은 단순히 DoS 공격에 노출될 뿐만 아니라, 의지가 있는 공격자에 의해 루트 권한을 획득할 수 있다는 점입니다.

엔터프라이즈 리눅스 현황을 면밀히 살펴볼 필요가 있습니다. 7월 8일 현재, 레드햇의 공개 CVE 페이지에는 모든 RHEL 커널(6, 7, 8, 9, 10 및 실시간 버전을 포함하여)이 kernel-rt)는 ‘영향을 받음’으로 분류되었으며, 위협 심각도는 ‘중요’로 지정되었고, 아직 정정 공지가 발표되지 않았습니다. 해당 페이지는 당일 중에 내용이 변경되었습니다. 7월 8일 이른 시간에는 RHEL이 취약하지 않은 것으로 표시되어 있었으며, 초기에 “EL은 영향을 받지 않음”이라고 해석한 내용은 현재 대체된 그 버전을 바탕으로 한 것이었습니다. 이번 사례는 보안 권고문을 한 번 읽고 넘어갔다면 잘못된 결론을 내렸을 수 있는 경우입니다.

레드햇의 기술적 수정 사항은 이미 CentOS Stream(차기 RHEL 커널의 롤링 프리뷰)에 조용히 반영되었습니다. Stream 9에서는 다음에서 수정되었습니다. kernel-5.14.0-716.el9 그리고 다음 부분에서 취약점을 보였는데 kernel-5.14.0-699.el9. 스트림 10은 다음에서 수정되었습니다. kernel-6.12.0-239.el10 그리고 다음 부분에서 취약점을 보였는데 kernel-6.12.0-224.el10. CloudLinux 9 및 10은 AlmaLinux와 EL9/EL10 커널을 기반으로 하므로, 해당 Stream 수정 사항은 이러한 버전에 적용됩니다. 따라서 실제로 해야 할 작업은 현재 배포 중인 일반 커널이 수정된 커널과 취약점이 있는 커널의 경계 중 어느 쪽에 속하는지 확인하는 것입니다. EL7 및 EL8의 경계는 아직 확인되지 않았습니다.

지금 바로 위험을 줄이세요

솔직히 말해서, 호스트 전체에 적용되는 명확하고 포괄적인 런타임 완화책은 없습니다.

이 버그가 발생하기 위한 유일한 전제 조건은 CONFIG_FUTEX_PI, 그리고 이는 런타임 스위치가 없는 빌드 시 옵션입니다. 이는 glibc의 우선순위 상속 뮤텍스에 필수적이므로, 해당 잠금 장치를 사용하는 사용자 공간 프로그램의 작동을 방해하지 않고는 실행 중인 프로덕션 커널에서 이 기능을 비활성화할 수 없습니다. 블랙리스트에 추가할 모듈도 없고, 설정값을 변경할 수 있는 옵션도 없습니다.

그러면 패치 적용과 워크로드별 조정 수단 하나만 남게 됩니다.

컨테이너 및 샌드박스화된 워크로드. futex의 우선순위 상속 작업을 차단하는 seccomp 정책(프로그램이 호출할 수 있는 시스템 호출을 필터링하는 리눅스 기능)은, FUTEX_LOCK_PI, FUTEX_WAIT_REQUEUE_PI, 그리고 FUTEX_CMP_REQUEUE_PI, 트리거를 닫습니다. 견고한 필터는 변형 사례들도 모두 포함해야 하며, futex_time64 시스템 호출 및 아키텍처별 시스템 호출 번호, 그리고 FUTEX_LOCK_PI2 최신 커널에서는 이 문제를 우회할 수 있습니다. 단, 우선순위 상속 뮤텍스를 사용하는 모든 워크로드가 정상적으로 작동하지 않게 되므로, 배포 전에 반드시 테스트해야 합니다. 또한 이 설정은 “컨테이너 탈출”이라는 개념이 실제로 가능하게 만드는 요인이기도 합니다. 즉, 런타임이 이미 이러한 futex 연산을 필터링하지 않는 한, 컨테이너 내부의 비특권 코드도 이 버그에 도달하게 됩니다.

그 외의 모든 경우. 벤더의 커널 업데이트나 KernelCare의 재부팅 없이 적용 가능한 패치를 적용하는 것 외에는 시스템 전체에 적용할 수 있는 완화 조치가 없습니다.

결정적인 순간입니다. 컨테이너나 샌드박스를 운영 중이고, 우선순위 상속 잠금(priority-inheritance locks)의 손실을 감수할 수 있다면, 본격적인 수정 조치를 계획하는 동안 임시 방편으로 seccomp 필터를 적용하십시오. 범용 호스트의 경우, 유일한 실질적인 해결책은 수정된 커널이나 재부팅 없이 적용 가능한 패치뿐이므로, 이를 최우선 순위로 처리하고, 해당 조치가 적용될 때까지 신뢰할 수 없는 로컬 실행을 격리하십시오. 이미 배포된 Debian 13 및 EL9 업데이트와 Ubuntu 24.04, Proxmox VE 8, AlmaLinux 전용 빌드를 우선적으로 적용하고, Debian 12 및 EL10의 경우 프로덕션 피드 승격이 진행 중인 동안에는 적절한 경우 테스트 피드를 활용하십시오.

우선순위별 개선 조치 체크리스트

1. 이 문제를 CVE-2026-43499(GhostLock)로 추적하고, 실행 중인 커널이나 재부팅 없이 적용되는 patchlivepatch에 주요 수정 사항인 3bfdc63936dd가 포함되어 있는지 확인하십시오. CVE-2026-53166으로 추적된 후속 변경 사항은 업스트림에서 되돌려졌으므로, GhostLock 대응 여부를 확인하는 데는 필요하지 않습니다.
2. 다음으로 빌드된 2.6.39-rc1부터 7.1-rc1 범위의 모든 커널을 CONFIG_FUTEX_PI 반증이 있을 때까지 해당 사항이 적용된 것으로 간주한다.
3. 로컬 격리가 보안 경계 역할을 하는 호스트를 우선적으로 고려하십시오. 여기에는 공유 호스팅, 멀티테넌트 노드, CI 러너, 그리고 신뢰할 수 없는 코드가 실행되는 컨테이너 및 개발자 호스트가 포함됩니다.
4. Enterprise Linux의 경우, 단일 권고문을 무작정 신뢰하기보다는 각 호스트가 ‘수정된 커널’과 ‘취약점이 있는 커널’의 경계 중 어느 쪽에 속하는지 확인하십시오. Stream 9는 다음에서 수정되었습니다. kernel-5.14.0-716.el9, 스트림 10은 다음 위치에 고정됨: kernel-6.12.0-239.el10; EL7 및 EL8 경계는 아직 확정되지 않았습니다.
5. 즉시 패치를 적용할 수 없고 워크로드가 허용하는 경우, 컨테이너와 샌드박스 내에서 futex 우선순위 상속 작업을 차단하는 seccomp 필터를 적용하십시오.
6. 비활성화하지 마십시오 CONFIG_FUTEX_PI 실행 중인 커널에서; 이는 glibc의 우선순위 상속 뮤텍스를 손상시키며, 지원되는 완화 조치가 아닙니다.
7. 사용 가능한 Debian 13, EL9, Ubuntu 24.04, Proxmox VE 8 및 AlmaLinux 전용 빌드 수정 사항을 지금 바로 적용하고, Debian 12와 EL10의 경우 테스트 피드를 활용하며, Debian 11, Amazon Linux 2023 및 EL7에 대한 수정 사항이 반영되는 대로 계속 추적하십시오.
8. 찾기 core_pattern 변경 사항, rtmutex-path 커널 경고, 원인을 알 수 없는 권한 상승 등을 고려하고, 파일 해시 값이 정상이라고 해서 호스트에 대한 충분한 증거로 간주하지 않습니다.
9. 고정된 벤더 커널을 적용한 후 시스템을 재부팅하거나, 현재 실행 중인 커널에 맞는 KernelCare 재부팅 불필요 패치를 사용하되, 재부팅이 가장 어려운 호스트를 우선적으로 처리하십시오.

탐지

GhostLock은 디스크에 신뢰할 만한 흔적을 남기지 않습니다. 손상은 커널 메모리 내에서 발생하며, 문서화된 종료 단계에서는 파일을 수정하는 대신 커널 설정을 변경하므로, 공격이 발생한 후에도 파일 무결성 검사 도구는 정상 상태를 유지할 수 있습니다. 이로 인해 탐지는 행동 기반 분석 영역으로 넘어가게 됩니다. 다음 신호들은 공개된 익스플로잇 체인에서 도출된 것으로, 각각은 단서일 뿐 증거는 아닙니다:

• 예상치 못한 변경 사항이 /proc/sys/kernel/core_pattern, 또는 해당 권한, 특히 충돌 시 외부 프로그램을 실행하는 핸들러를 악용하여. 퍼블릭 체인은 결국 core_pattern 루트 권한을 얻으려면.
• futex 우선순위 상속 연산을 반복적으로 수행하는 비특권 프로세스(FUTEX_LOCK_PI, FUTEX_WAIT_REQUEUE_PI, FUTEX_CMP_REQUEUE_PI) 여러 스레드에 걸쳐 발생하며, 이는 교착 상태 경로를 유발하는 것과 일치한다.
• rtmutex(실시간 뮤텍스) 코드에서 커널 오류(oops) 또는 경고가 발생하는 부분, 대략 remove_waiter(), rt_mutex_start_proxy_lock()또는 rt_mutex_adjust_prio_chain(), 이에 상응하는 하드웨어 오류는 없습니다.
• 사용법 PR_SET_MM_MAP 위의 사례와 시간적으로 가까운 시점에, 자체 메모리 레이아웃을 재작성할 정당한 이유가 없는 프로세스에 의해 발생합니다.
• futex 및 rtmutex의 불안정 현상이 집중적으로 발생한 직후, 이에 상응하는 sudo 또는 로그인 이벤트 없이 로컬 계정이나 서비스가 권한을 획득하는 경우.

최근 커널 메시지 확인:

journalctl -k --since "24 hours ago" | grep -Ei 'rtmutex|pi_blocked|remove_waiter|BUG|WARNING'

이러한 메시지가 없다고 해서 해당 호스트에 패치가 적용되었거나 침해되지 않았다는 증거가 되는 것은 아닙니다. 교묘한 공격자는 경고가 발생하지 않도록 할 수 있으며, 취약점이 있는 경로가 아직 실행되지 않았을 수도 있습니다. 노출 기간 동안 영향을 받은 호스트에서 신뢰할 수 없거나 부분적으로만 신뢰할 수 있는 로컬 코드가 실행된 경우, 파일 해시가 정상이라고 해서 안전하다고 단정 짓기보다는 해당 호스트를 면밀히 조사해야 할 대상으로 간주해야 합니다. 이때 새로운 계정, 변경된 인증 구성, 예상치 못한 서비스 등을 확인해야 합니다.

GhostLock이 중요한 이유

GhostLock은 원격 코드 실행이 아닌 로컬 권한 상승 공격입니다. 이것만으로는 인터넷을 통해 서버에 루트 권한을 획득할 수 있는 사람은 아무도 없습니다. 하지만 실제로 이 공격이 발생하는 환경에서는 그나마 위안이 될 뿐입니다.

공유 호스팅은 고객의 코드를 실행합니다. CI 러너는 가장 최근의 풀 리퀘스트에 명시된 대로 코드를 실행합니다. 컨테이너와 쿠버네티스 노드는 다양한 신뢰 수준에서 워크로드를 실행하며, 멀티테넌트 호스트는 테넌트 간 격리를 위해 특별히 존재합니다. 이 모든 환경에서 ‘로컬 권한 상승’은 전체 설계가 방지하고자 하는 사건입니다. 이는 실행이 허용되었던 코드를, 절대 실행되어서는 안 되는 루트 권한으로 실행되는 코드로 변모시킵니다.

오판하기 쉬운 이유가 바로 이것이 위험한 이유이기도 합니다. 세 가지 그럴듯한 신호가 모두 “안전”을 가리키지만, 모두 오해를 불러일으킵니다. 이 버그의 발생 시기는 마치 박물관 전시품처럼 오래전 일처럼 보이지만, 사실 오늘날의 기본 커널에서도 이 버그에 접근할 수 있습니다. futex 기능은 마치 틈새 기술처럼 보이지만, 사실상 모든 배포판에 컴파일되어 있으며 glibc의 표준 잠금 기능에서도 사용되고 있습니다. 또한 7월 8일 아침에 한 번 확인했던 보안 권고문에서는 RHEL이 취약하지 않다고 밝혔을 수 있었으나, 불과 몇 시간 후 같은 페이지에는 모든 RHEL 커널이 영향을 받는 것으로 표시되었습니다. 이 중 어느 하나라도 믿었다면, 취약한 호스트를 안전하다고 처리했을 것입니다.

GhostLock은 바로 재부팅 없이 패치를 적용할 수 있는 기능이 필요한 유형의 버그입니다. 업스트림 변경 사항은 이미 제공되고 있지만, 이는 실행 중인 시스템을 보호해 주지는 않습니다. 공급업체가 해당 변경 사항을 백포트해야 하고, 사용자가 패키지를 설치해야 하며, 시스템이 새로운 커널로 부팅되어야 하기 때문입니다. 멀티테넌트 및 컨테이너 클러스터 환경에서는 이 마지막 단계로 인해 알려진 로컬 루트 권한 획득 버그로 인한 노출 위험이 수 주간 지속될 수 있으며, 특히 가장 큰 위험에 처한 호스트에서 그 부담이 가장 큽니다.

이 변경 사항은 재부팅 없이 적용할 수 있는 패치의 좋은 후보입니다. 데이터 구조의 레이아웃 변경이 없고, 유지되어야 할 영구적인 상태도 없는, 잠금 경로에 대한 작고 독립적인 수정 사항이기 때문입니다. KernelCare는 주요 GhostLock 수정 사항인 3bfdc63936dd를 실행 중인 커널에 포팅합니다. 참고: 이는 사용자 공간 라이브러리 구성 요소가 없는, 커널 전용 버그입니다.

2026년 7월 10일 17:00 (UTC) 기준 라이브 패치(KernelCare) 릴리스 현황.

메인 피드:

• EL9 계열: RHEL 9, AlmaLinux 9, Oracle Linux 9, Rocky Linux 9
• AlmaLinux 9 LTS 및 AlmaLinux 9 FIPS 9.6
• 우분투 24.04
• Proxmox VE 8

테스트 피드:

• EL10 제품군: RHEL 10, AlmaLinux 10, Rocky Linux 10, Oracle Linux 10
• 데비안 12

공급업체 측에서 수정 및 공개됨:

• 데비안 13

진행 중이거나 아직 공개되지 않은:

• Amazon Linux 2023: 빌드 완료, 아직 출시되지 않음
• 데비안 11: 검토 대기 중
• EL7: 적용 여부 미정
• EL6: 우선순위 낮음

KernelCare 패치 정보에는 CVE-2026-43499만 언급되어 있으며, 이 CVE를 통해 GhostLock에 대한 패치가 적용되었음을 확인할 수 있습니다. CVE-2026-53166으로 추적된 후속 변경 사항은 회귀 현상으로 인해 업스트림에서 되돌려졌으므로, 해당 변경 사항을 통해 패치 적용 범위를 확인할 필요는 없습니다.

K-태그가 제공되면 테스트 피드에서 적용하세요:

kcarectl --update --prefix test

프로모션이 완료되면 프로덕션 피드에서 적용하세요:

kcarectl --update

빌드 날짜를 맹신하기보다는 GhostLock의 CVE 매핑을 확인하십시오:

kcarectl --info | grep kpatch-build-time      # build dated 2026-07-08 or later
kcarectl --patch-info | grep 'CVE-2026-43499'

빌드 날짜만으로는 아무것도 확인할 수 없습니다. 4월 중순 이후에 컴파일된 커널이라고 해서 자동으로 GhostLock 수정 사항이 포함된 것은 아니기 때문입니다. CVE 매핑, 공급업체의 오류 수정 공지, 소스 코드 또는 rebootless-patch 상태를 직접 확인하십시오.

GhostLock은 15년 전의 잠금 관련 오류를 로컬 권한 경계의 취약점으로 전환시킵니다. 긴급 재부팅을 감당할 수 없는 대규모 시스템 환경의 경우, 재부팅이 필요 없는 패치를 통해 노드를 중단시키거나 워크로드를 방해하지 않고도 실행 중인 커널 내에서 해당 경계를 차단할 수 있습니다.

지금 바로 KernelCare를 다운로드하세요 →

연표

참조

• IonStack 2부: GhostLock, Nebula Security, 2026년 7월 7일: https://nebusec.ai/research/ionstack-part-2/
• 버그 목록 항목, CVE-2026-43499: https://nebusec.ai/buglist/CVE-2026-43499
• 공개 PoC, CyberMeowfia/IonStack/CVE-2026-43499: https://github.com/NebuSec/CyberMeowfia/tree/main/IonStack/CVE-2026-43499
• 업스트림 수정 3bfdc63936dd (“rtmutex: remove_waiter()에서 current 대신 waiter::task를 사용하십시오”): https://git.kernel.org/linus/3bfdc63936dd4773109b7b8c280c0f3b5ae7d349
• 후속 변경 사항 74e144274af3(CVE-2026-53166; 이후 회귀 현상으로 인해 업스트림에서 되돌림)을 되돌렸습니다: https://git.kernel.org/linus/74e144274af39935b0f410c0ee4d2b91c3730414
• 버그를 유발한 커밋 8161239a8bcc (“rtmutex: PI 알고리즘을 단순화하고 최우선순위 작업이 잠금을 획득하도록 함”), v2.6.39-rc1에 포함됨
• Red Hat CVE-2026-43499 (RHEL 6-10 커널 / kernel-rt가 영향을 받는 것으로 표시됨, 심각도: 중요, BZ 2480453): https://access.redhat.com/security/cve/cve-2026-43499
• CentOS Stream 자동 수정 사항: cs9 4e5a31ae1fa9, cs10 7bba8926cefe
• 언론 보도: The Hacker News, “15년 된 GhostLock 취약점으로 루트 권한 획득 가능…”: https://thehackernews.com/2026/07/15-year-old-ghostlock-flaw-enables-root.html