인피니티 코어, 커널의 ‘조용한’ 부분도 안전하지 않음을 입증하다

요약

전체 버전으로 이동 ↓

개요: ‘Infinity Core’는 김현우(@v4bel)가 커널 핵심 코드에 존재하는 6가지 버그에 붙인 이름으로, POSIX CPU 타이머, 신호 전달, 페이지 테이블 워커, futex, 스케줄러 캐시 회계 및 SLUB 할당기를 포함합니다. 김현우는 linux-distros의 공개 금지 기간이 만료되자마자 2026년 10월 16일 oss-security에 세부 내용과 익스플로잇 코드를 게시했습니다. 이 섹션으로 이동 →

영향: 6개 중 5개는 일반 비특권 계정에서 시작하여 루트 셸을 획득하는 공개 개념 증명(PoC)이 제공됩니다. 김 씨는 또한 이 5개를 컨테이너 탈출 사례로 분류합니다. 여섯 번째인 SLUB의 경우, 현재로서는 커널에 패닉을 유발할 뿐입니다. 이 섹션으로 이동 →

중요도: 점수만으로는 상황을 제대로 파악하기 어렵습니다. Amazon Linux는 CVSS 3.1 기준 타이머 및 신호 관련 버그에 7.0, MM 버그에 6.3을 부여했으며, 이들 모두 로컬 공격 벡터와 높은 공격 난이도를 가지고 있습니다. 이러한 등급은 작동하는 루트 익스플로잇이 공개되기 전에 책정된 것입니다. 이 섹션으로 이동 →

누가 영향을 받나요: 우분투 26.04가 가장 큰 타격을 입었습니다. 타이머, 시그널, MM 및 futex 버그에 대한 루트 권한 획득 코드는 이 버전에서 작성되고 테스트되었습니다. 7.0.0-30-generic 커널의 경우, TuxCare의 커널 팀은 우분투 26.04에서도 이 네 가지 취약점을 모두 이용해 루트 권한을 획득하는 현상을 재현해 냈습니다. 타이머 버그는 EL9 및 EL10 커널, 데비안 12와 13, 우분투 24.04에도 영향을 미치며, TuxCare의 테스트 결과 이 환경에서는 시스템 충돌이 발생했으나 루트 권한 획득까지는 이르지 않았습니다. 적어도 아직까지는 그렇습니다. 스케줄러 및 SLUB 버그는 7.2 버전 이후에서만 존재합니다. 이 섹션으로 이동 →

상태: 6건 모두에 대해 업스트림에서 수정 사항이 제공되었으며, CVE 기록 중 4건은 9월 4일부터 10월 6일 사이에 이미 공개된 바 있습니다. 배포판 커널의 대응 속도는 제각각입니다. 예를 들어, 데비안(Debian)은 이미 ‘bookworm’과 ‘trixie’에 대한 수정된 보안 커널을 배포했으며, 레드햇(Red Hat)은 지난 10월 1일에 RHEL 9용 futex 버그를 수정했습니다. 실제 환경에서 악용된 사례는 보고된 바가 없습니다. 이는 제로데이가 아닌, 공개된 익스플로잇이 존재하는 n-데이 취약점들입니다.

지금 당장 이렇게 하세요: 비활성화할 수 있는 sysctl이나 모듈은 알려진 바가 없습니다. 먼저 우분투 26.04 호스트에 수정된 커널을 적용하세요. 특히 공유 호스팅 서버, CI 실행 서버, 다중 테넌트 컨테이너 호스트 등 완전히 신뢰할 수 없는 출처의 코드를 실행하는 시스템부터 우선적으로 처리하십시오. 사용 중인 배포판에 이미 수정 패치가 포함되어 있다면 이를 설치하고 재부팅을 계획하십시오. 비특권 사용자 네임스페이스를 비활성화해도 소용이 없습니다. 이 버그들 중 어느 것도 비특권 사용자 네임스페이스를 필요로 하지 않기 때문입니다. 실제로 실행 중인 커널을 확인하려면:

uname -r

이를 업스트림 버전 번호가 아닌, 공급업체의 권고 사항과 비교해 보십시오. 배포판 커널은 기본 버전을 올리지 않고도 수정 사항을 백포트합니다.

이 섹션으로 이동 →

뉴스에 보도되는 커널 권한 상승 사례 중 상당수는 몇 가지 특정 영역에서 발생합니다. 네트워킹, 소켓, BPF, perf 등이 바로 그 예입니다. 이러한 버그들은 비특권 사용자 네임스페이스를 통해 접근해야만 발생합니다. 보안 강화 가이드들은 수년 동안 관리자들에게 이러한 영역을 격리하도록 교육해 왔으며, 많은 조직이 실제로 그렇게 했습니다.

인피니티 코어는 이 모든 것을 우회합니다. 김 씨는 의도적으로 해당 영역들을 제외하고, 모든 프로세스가 아무런 의심 없이 실행하는 코드, 예를 들어 다음과 같은 부분을 살펴보았습니다. exec(), 신호 처리, mincore() 그리고 futex도 마찬가지였습니다. 조사 결과, 기본 설정의 Ubuntu 26.04 설치 환경에서는 4건의 루트 익스플로잇이 발견되었고, Arch Linux에서는 1건이 더 발견되었으며, 이를 제거할 수 있는 알려진 sysctl 설정이나 모듈 변경 사항은 없었습니다.

수정 사항은 이미 업스트림에 반영되었습니다. 많은 호스트에서 놓치고 있는 점은 이러한 수정 사항이 적용된 정상 작동하는 커널이 없다는 것입니다.

10월 16일에 도착한 것

김 씨는 해당 버그들을 비공개로 제보한 뒤, linux-distros 메일링 리스트를 통해 해결 과정을 거쳤으며, 2026년 10월 16일 공개 금지 기간이 만료되자 이를 공개했습니다. oss-security 게시물과 InfinityCore 저장소에는 버그별 분석 자료와 익스플로잇 코드가 수록되어 있습니다. 김 씨가 이 블로그에 등장한 것은 이번이 처음이 아닙니다. 바로 이 연구원이 올해 초 KVM 탈출 취약점인 Januscape와 Zapscape를 발견한 바 있습니다.

6건 중 4건은 공개일 이전에 이미 공개된 CVE 기록이 있었습니다. 커널 CNA는 9월 4일에 futex 관련 CVE를, 9월 11일에 MM 관련 CVE를, 10월 6일에는 타이머 및 신호 관련 CVE를 공개했습니다. 각 CVE는 커널 CVE에서 흔히 볼 수 있는, 간결하고 커밋 스타일의 제목으로 공개되었으며, 루트 익스플로잇이 등장할 것이라는 암시는 전혀 없었습니다. 정리 패치처럼 보이는 CVE는 다음 유지보수 기간까지 미뤄두기 쉽습니다. 하지만 GitHub에 루트 익스플로잇이 포함된 동일한 CVE가 올라와 있다면 이야기는 달라집니다.

아직 공개되지 않은 부분이 하나 남아 있습니다. 김 씨는 이 타이머 버그가 일반 앱에서 실행해도 삼성 갤럭시 S26 울트라에서 완전한 루트 권한을 부여한다고 밝혔으며, 이 취약점은 삼성이 수정 패치를 배포하거나 다른 누군가가 먼저 공개할 때까지 비공개로 유지될 것이라고 말했습니다.

타이머와 신호 관련 버그는 동일한 트리거를 공유하는데, 이 트리거는 다소 특이합니다. 프로세스 리더가 아닌 스레드가 exec() 작업이 충분히 진행되면, 커널은 스레드 ID를 교체하여 호출한 스레드가 새로운 리더 역할을 맡게 합니다. 두 버그 모두 이 교체 과정 주변의 정리 작업에서 발생합니다.

CVE-2026-98260, 즉 타이머 버그가 발생하려면 해당 스레드에서 스레드별로 설정된 POSIX CPU 타이머가 활성화되어 있어야 합니다. 만약 exec() 그런 다음 ID 교환 후 오류가 발생하면, 해당 노드가 여전히 활성 상태인 작업의 대기열에 남아 있는 동안 타이머가 해제되고, 이후 정리 과정에서 해제된 노드를 그대로 처리하게 됩니다. 전형적인 ‘use-after-free’ 취약점입니다. 공개된 익스플로잇은 이를 통해 우분투 26.04에서 루트 셸을 획득하며, 수정 사항은, acb03d388181, 타이머 정리 작업을 바로 그 직후로 이동합니다 de_thread() 그래서 [ ] 때 미해결된 문제가 남지 않도록 exec() 보석.

CVE-2026-98256, 이른바 ‘신호 버그’는 동일한 시점을 둘러싼 경합 현상입니다. 한 경로는 잠금을 걸지 않은 채 종료 중인 리더의 보류 중인 신호를 비우는 반면, 다른 경로는 스왑된 PID를 따라가며 sigqueue 새로운 리더의 큐에 항목이 추가됩니다. 링크를 변조하면 해당 항목은 속해 있던 객체보다 더 오래 남아 있게 됩니다. 김 씨의 익스플로잇은 이 잔여 항목을 오라클로 활용하여 해제된 메모리가 언제 재사용되었는지 파악한 뒤, 조작된 신호를 큐에서 제거하는 경로를 악용하여 루트 셸을 획득합니다. 해결 방법은 다음과 같습니다. d2710c8d938a.

프로그램 오류 exec() 하루 종일. 잘못된 경로, 누락된 인터프리터, 부적절한 타이밍의 신호 등. 하지만 이 중 어느 하나만으로는 두 버그가 모두 발생하지는 않습니다. 타이머 버그는 스레드 ID 교환 후 착륙에 실패해야만 발생하고, 신호 버그는 공격자가 바로 그 교환 과정에서 경합을 이겨내야만 발생합니다. 외부에서 보면 이러한 시도는 여전히 평범한 프로세스 활동으로 보이기 때문에, 패치를 적용하는 것 외에는 이를 걸러낼 명확한 방법이 없습니다.

CVE-2026-89754는 페이지 테이블 워커에 존재합니다. 다음 조건이 동시에 발생하는 경우 madvise(MADV_DONTNEED), 하위 레벨의 재시도 플래그가 상위 레벨로 유출되고, mincore() 동일한 범위를 두 번 순회합니다. 이때 출력 커서는 이미 다음 위치로 이동한 상태이므로, 두 번째 순회에서는 정확히 한 페이지 길이의 임시 버퍼를 지나쳐 쓰기가 이루어집니다. 킴의 익스플로잇은 자격 증명 슬래브를 바로 다음 물리 페이지에 배치하고, 오버플로를 이용해 struct cred. 커널 LPE보다 더 직접적인 예는 없을 정도입니다. 해결 방법은 다음과 같습니다. aedf2efd1897.

CVE-2026-80775, 이른바 ‘futex 버그’는 두 개의 태스크가 하나의 mm_struct, 이는 중첩되어 vfork() 중간 노드가 파괴되면 발생합니다. 두 노드 모두 비공개 futex 해시에 대한 첫 번째 참조 카운터를 설치하려고 경쟁합니다. 저장 작업은 하나만 성공하므로, 다른 카운터에 대한 참조는 더 이상 추적되지 않게 되고, 아직 사용 중인 해시가 해제됩니다. 이 익스플로잇은 파이프 링을 통해 이를 회수하고 다음의 페이지 캐시를 덮어씁니다. /usr/bin/passwd. 이렇게 하면 변경 사항이 디스크에 기록되지 않은 상태에서 커널이 해당 파일에 대해 제공하는 내용이 바뀌게 되므로, 캐시된 페이지가 삭제되거나 호스트가 재부팅되면 조작 흔적이 사라질 수 있습니다. 나중에 이를 조사하는 데 행운을 빕니다. 해결 방법은 다음과 같습니다. bde023808364.

대부분의 함대에게는 마지막 두 가지가 그다지 중요하지 않습니다. CVE-2026-98385는 스케줄러 캐시 회계 기능에서 발생하는 ‘사용 후 해제(use-after-free)’ 취약점으로, 다음이 필요합니다. CONFIG_SCHED_CACHE=y 이 빌드에서는 런타임 시 스케줄러 캐시 계정이 활성화되어 있으며, 최상위 캐시가 두 개 이상인 CPU 토폴로지가 적용되었습니다. 이 취약점을 악용하여 7.2.4 커널을 사용하는 Arch Linux에서 루트 권한을 획득했습니다. CVE-2026-97941은 SLUB 객체 재충전 과정에서 발생하는 ABA 경합(race)으로, 부분 목록을 손상시킵니다. 공개된 트리거는 커널을 패닉 상태로 만들 뿐이며, 이에 대한 루트 권한 획득 익스플로잇은 아직 공개되지 않았습니다. 두 취약점 모두 7.2 버전에서 처음 등장한 코드에 존재하므로, KernelCare가 지원하는 배포판 커널에는 이 중 어느 것도 포함되어 있지 않습니다.

이 글을 작성하는 시점에서 타이머 및 신호 버그에 대한 NVD 점수는 아직 확정되지 않았습니다. Amazon Linux는 이 중 세 가지에 대한 점수를 공개했으며, 해당 벡터와 관련된 타이머 및 신호 버그에 7.0점을 부여했습니다. AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H, 그리고 MM 버그에 대한 6.3.

그리고 AC:H 이 부분은 좀 더 면밀히 살펴볼 필요가 있습니다. 대부분은 경쟁 구도이며, 예전에는 “경쟁 중”이라는 사실만으로도 해당 항목을 우선순위 목록에서 뒤로 미루는 타당한 이유가 되곤 했습니다. 하지만 이미 경쟁에서 승리하는 데 필요한 어려운 과정을 거친 공개된 취약점이 등장하면 상황은 달라집니다. 신뢰할 수 없는 사용자가 코드를 실행할 수 있는 호스트에서 작동하는 루트 셸이 포함된 7.0 버전은 목록 상단에 위치해야 마땅합니다. 이는 단순한 숫자보다 훨씬 더 시급성을 잘 보여줍니다.

누가 먼저 걱정해야 할까

이들 모두는 기능도, 사용자 네임스페이스도, 특수 장치에 대한 접근 권한도 없는 평범한 로컬 계정에서 시작됩니다. 따라서 진짜 문제는 여러분이 완전히 통제하지 못하는 호스트에서 누가 코드를 실행할 수 있는가 하는 점입니다.

사용자용 SSH 또는 제어판 셸이 제공되는 공유 호스팅 서버가 가장 대표적인 예입니다. 임의의 풀 리퀘스트를 빌드하는 CI 러너도 또 다른 예입니다. 서로를 신뢰하지 않는 테넌트를 위해 컨테이너를 실행하는 모든 호스트도 마찬가지입니다. Kim은 이 다섯 가지 루트 버그를 모두 ‘컨테이너 탈출’로 분류하는데, 이는 타당한 분석입니다. 모든 컨테이너는 호스트 커널을 공유하며, 관련된 시스템 호출은 컨테이너 워크로드가 끊임없이 사용하는 일상적인 것들입니다. seccomp 프로파일이나 LSM 정책이 우연히 정확한 경로를 차단하지 않는 한, 컨테이너 경계만으로는 안전을 보장받을 수 없다고 봐야 합니다.

관리자가 세 명이나 있는 단일 용도 데이터베이스 서버의 경우는 사정이 다릅니다. 이 서버도 여전히 수정 작업이 필요하지만, 우선순위가 가장 높은 것은 아닙니다.

인피니티 코어는 제로데이 취약점인가요?

아닙니다. 모든 수정 사항은 취약점이 공개되기 전에 이미 업스트림에 반영되었으며, 가장 이른 CVE 기록은 공개 시점보다 약 6주 앞서 있습니다. 실제 환경에서 악용된 사례는 보고된 바가 없습니다. 이는 공개된 익스플로잇이 있는 ‘n-day’ 취약점이며, 이는 방어 측을 훨씬 더 어려운 처지에 빠뜨릴 수 있습니다. 이제 시간은 배포판이 수정된 커널을 얼마나 빨리 배포하고, 관리자가 실제로 그 커널로 시스템을 얼마나 빨리 부팅하느냐에 따라 결정됩니다.

2026년 10월 19일 기준, TuxCare의 자체 분석에 따른 KernelCare 지원 배포판 현황(각 벤더의 커널 상태와는 별개):

“현재까지의 충돌”이라는 표현에는 주의할 점이 있습니다. 특정 커널 빌드에서 작동하는 루트 익스플로잇은, 이를 적용하는 데 여전히 상당한 노력이 필요하더라도, 다음 빌드를 대비하는 데 있어 큰 발판이 됩니다. 해당 배포판에서는 루트 권한 획득이 확인되지는 않았지만, 로컬 권한 상승은 현실적인 위험 요소이므로, 패치 우선순위는 이를 반영해야 합니다.

앞서 언급했듯이, 버전 문자열만으로는 여기서 아무것도 결정할 수 없습니다. 오직 해당 커널에 대한 공급업체 권고 사항이나 검증된 패치만이 해결책이 됩니다.

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

왜 신속한 완화책이 없는가

최근 발생한 많은 커널 LPE의 경우, 임시 해결책은 한 줄짜리 코드면 충분했습니다. 모듈을 블랙리스트에 올리거나, sysctl 값을 변경하거나, 비특권 사용자 네임스페이스를 비활성화하는 식이었죠. 하지만 이번에는 그 어떤 방법도 통하지 않습니다. Kim은 사용자 네임스페이스가 필요한 버그들을 의도적으로 제외시켰고, 나머지 버그들은 exec(), 신호 처리, mincore() 그리고 정상적으로 작동하는 시스템에서는 언로드하거나 비활성화할 수 없는 futex 코드입니다. TuxCare는 아직 신뢰할 수 있는 해결 방법을 찾아내지 못했습니다. 비특권 사용자 네임스페이스를 비활성화하거나 모듈을 블랙리스트에 등록하는 등의 일반적인 조치들은 취약한 코드 경로에 영향을 미치지 않으며, 각 버그에 대해 별도로 검증된 해결 방법도 없습니다.

그러면 그다지 만족스럽지 않은 대안들만 남게 됩니다. 패치가 적용될 때까지 노출된 호스트에서 로컬 셸을 사용하는 사용자를 제한하십시오. 서로를 정말로 신뢰하지 않는 테넌트들은 공유 커널상의 컨테이너 대신 별도의 VM으로 옮기십시오. 그리고 커널 로그를 주의 깊게 모니터링하십시오. 이 중 몇 가지는 경합 상황이며, 시도가 실패할 경우 조용히 실패하는 대신 커널이 ‘oops’ 또는 ‘panic’ 상태를 일으킬 수 있습니다. 다만 로그에 오류가 없다고 해서 아무 일도 일어나지 않았다는 증거는 아닙니다:

journalctl -k | grep -iE 'BUG:|Oops|general protection'

이번 주 다중 사용자 호스트에서 발생한 원인을 알 수 없는 실수는 좀 더 자세히 살펴볼 필요가 있습니다.

영구적인 해결책은 배포판에서 제공하거나 직접 빌드한, 업스트림 패치가 적용된 커널을 사용하는 것입니다. 패키지를 설치한다고 해서 메모리에서 이미 실행 중인 커널에는 영향을 미치지 않으므로, 호스트가 새로운 커널로 부팅하기 전까지는 아무것도 변경되지 않습니다. 실제로 어떤 커널이 실행 중인지 확인해 보세요:

uname -r

고정된 커널을 설치한 후 한 번도 재부팅하지 않은 호스트는 여전히 취약점이 있는 커널을 실행 중입니다. 공유 호스팅 서버와 CI 풀은 재부팅을 하면 고객에게 경고해야 하거나 진행 중인 작업을 중단시켜야 하기 때문에, 이러한 문제가 가장 심각하게 나타나는 경향이 있습니다.

커널용으로 출시되면, KernelCare의 재부팅 불필요 패치는 재부팅 없이도 실행 중인 커널에 수정 사항을 적용합니다. 자동 업데이트가 활성화된 경우, 패치가 실행 중인 커널용 피드에 등록되면 다음 예정된 점검 시 해당 패치가 적용되며, kcarectl --update 필요할 때마다 이를 요청합니다. 지원되는 배포판 커널에 영향을 미치는 네 가지 버그에 대한 적용 범위를 확인하려면:

kcarectl --patch-info | grep -E 'CVE-2026-(98260|98256|89754|80775)'

스케줄러 및 SLUB 관련 CVE는 지원되는 배포판 커널 중 어느 것도 이를 포함하고 있지 않기 때문에 의도적으로 해당 패턴에서 제외되었습니다. 2026년 10월 19일 현재, Infinity Core에서 공개한 유일한 패치는 AlmaLinux 9 커널 스트림용 futex 수정 패치뿐입니다. 아직 어떤 배포판에서도 타이머 버그에 대한 패치가 제공되지 않았으며, Ubuntu 26.04의 4가지 버그에 대한 패치도 마찬가지입니다. 향후 며칠 동안의 업데이트 소식은 이 게시물을 확인해 주시기 바랍니다. 패치가 사용자의 스트림에 도달하면, KernelCare가 실제로 실행 중인 커널에 해당 패치를 적용했는지 확인하고, 관련 CVE에 대한 적용 범위가 검증될 때까지 접근 권한을 엄격하게 제한해 주십시오.

인피니티 코어가 중요한 이유

감소를 통한 강화에는 한계가 있다. 관리자들은 필요 없는 공격 표면을 제거하는 데 능숙해졌으며, 그 노력이 결실을 맺고 있습니다. 하지만 아무도 다음을 제거할 수는 없습니다. exec(). 김 씨는 보안 이력이 별다른 문제가 없는 하위 시스템들을 샅샅이 조사한 끝에 6개의 버그를 찾아냈다. 성숙하고 널리 사용되는 코드가 반드시 안전한 코드인 것은 아니며, 보안 강화만으로는 그 격차를 메울 수 없다.

신뢰할 수 없는 로컬 사용자가 있는 Ubuntu 26.04를 실행 중이라면, 이것이 이번 주 가장 먼저 처리해야 할 패치 작업입니다. EL, 데비안(Debian) 및 우분투 24.04 호스트의 경우, 테스트 단계에서는 아직 해당 환경에서 크래시만 발생했을 뿐이지만, 공개된 우분투 익스플로잇으로 인해 루트 권한 획득이 현실적인 다음 단계가 될 수 있으므로 타이머 버그에 최우선 순위를 두어야 합니다. 또한 재부팅이 CI 풀을 소진시키거나 수백 명의 호스팅 고객에게 이메일을 보내야 하는 상황을 초래할 경우, KernelCare의 재부팅 없이 적용 가능한 패치는 유지보수 시간대 없이도 패치가 제공되는 즉시 실행 중인 커널에서 이러한 버그를 수정하도록 설계되었습니다.

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

연표

참조

oss-security에 게시된 Kim의 Infinity Core 관련 글 (2026년 10월 16일), 익스플로잇 코드와 버그별 분석 자료가 포함된 InfinityCore 저장소, CVE-2026-98260, CVE-2026-98256, CVE-2026-89754, CVE-2026-80775, CVE-2026-98385 및 CVE-2026-97941에 대한 기록, 타이머 수정 커밋 acb03d388181 및 futex 수정 커밋 bde023808364를 포함하여 김 씨의 저장소에 나열된 전체 업스트림 수정 커밋 세트, CVE-2026-98260에 대한 데비안(Debian) 보안 트래커 항목, 레드햇의 RHSA-2026:74438, 그리고 아마존 리눅스의 CVE-2026-98260, CVE-2026-98256 및 CVE-2026-89754에 대한 평가 점수.