'Bad Epoll'(CVE-2026-46242): 리눅스 커널 use-after-free가 AI 감사망까지 피해간 이유

epoll은 nginx, Node.js, Python asyncio, 각종 데이터베이스는 물론 안드로이드의 이벤트 루프까지
떠받치는 리눅스의 핵심 I/O 멀티플렉싱 기능입니다. 그런데 2026년 5월, 이 epoll 서브시스템에서
일반 사용자 권한만으로 root를 딸 수 있는 use-after-free 취약점이 공개됐습니다. 더 흥미로운 지점은
같은 코드 조각을 앤트로픽의 리서치용 AI 모델이 먼저 감사(audit)해서 다른 취약점 하나는 잡아냈지만,
정작 이 취약점은 그냥 지나쳤다는 사실입니다. 이 글에서는 ‘Bad Epoll’로 불리는 이 취약점(CVE-2026-46242)의
원인과 영향 범위, 그리고 AI 코드 감사가 어디서 한계를 보였는지 정리합니다.

Contents:

Bad Epoll(CVE-2026-46242)이란

Bad Epoll은 리눅스 커널 epoll 서브시스템의 use-after-free 경쟁 조건(race condition) 취약점입니다.
CVSS 점수는 7.8(High, 벡터스트링 AV:L/AC:L/PR:L)로, 로컬 접근만 가능하면 되고 별도의 권한 상승이나
특수 capability 없이 일반 사용자 계정만으로 공격이 가능합니다. 연구자 Jaeyoung Chung이 발견해 2월에
비공개로 제보했고, 공개된 PoC(개념 증명 코드)는 커널 메모리 유출과 간접 호출(indirect call) 제어를 결합한
ROP 체인으로 root 권한을 획득하며, 6.12 커널 기준 약 99%의 성공률을 보였다고 보고됐습니다.

취약점의 기술적 원인 — file->f_ep를 둘러싼 경쟁

문제는 fs/eventpoll.c의 정리(cleanup) 경로에서 두 스레드가 file->f_ep를 두고
경쟁하면서 발생합니다. 한쪽 경로(ep_remove())는 file->f_lock을 쥔 채
file->f_ep를 초기화하면서도 해당 파일 구조체를 계속 참조하려 하고, 다른 쪽 경로
(__fput())는 이미 NULL이 된 f_ep를 보고 epoll 관련 정리를 건너뛴 뒤
f_op->release()를 호출해 struct eventpoll 객체를 즉시 해제해버립니다.
그 결과 앞선 경로의 hlist_del_rcu() 호출이 이미 해제된 메모리에 8바이트를 쓰게 되는 것이
use-after-free의 핵심입니다. 경쟁 윈도우는 명령어 6개 정도로 매우 좁지만, 그럼에도 공개된 PoC는
높은 재현율을 보였습니다.

이 버그는 2023년 4월 커밋 58c9b016e128(메인라인 v6.4)에서 처음 만들어졌고, 2026년 4월 24일
커밋 a6dc643c6931로 수정됐습니다. 수정 방식은 epi_fget()과 __free(fput)
가드를 이용해 정리 과정 내내 파일 refcount가 0으로 떨어지지 않도록 미리 고정해두는 방식입니다.

왜 AI 코드 감사도 이 버그를 놓쳤나

흥미로운 부분은 앤트로픽의 리서치용 AI 모델 Mythos가 정확히 같은 epoll 코드 구간을 감사해
또 다른 취약점(같은 2023년 커밋에서 함께 생긴 자매 경쟁 조건, CVE-2026-43074)은 성공적으로 찾아내
보고했다는 사실입니다. 하지만 Bad Epoll 자체는 그냥 지나쳤습니다. 보도에 따르면 미세한 기계 명령어
단위의 타이밍에 의존하는 멀티스레드 경쟁 조건은 실행 흐름을 시간축으로 깊이 있게 추적해야 하는데,
현재의 AI 코드 감사 모델은 코드의 일반적 패턴을 식별하는 데는 강하지만 이런 비결정적(non-deterministic)
타이밍 문제에는 한계를 보인다는 설명입니다. 게다가 CVE-2026-43074가 먼저 수정되고 나면 Bad Epoll의
use-after-free는 대개 KASAN(커널의 대표적인 메모리 오류
탐지 도구)조차 잘 트리거하지 않아서, 자동화된 도구가 확신을 갖고 버그로 판단하기 더 어려웠을 것으로
추정됩니다.

영향 범위와 패치 타임라인

버그를 심은 커밋이 메인라인 v6.4에 들어갔기 때문에, v6.4 이상 커널이 전부 영향권입니다(6.18.x, 7.0.x
계열 포함). 다만 각 배포판이 보안 패치를 별도 브랜치에 백포트하는 경우가 많아, 정식 버전 표기만으로는
안전 여부를 판단할 수 없습니다. 예를 들어 5.14 기반의 일부 엔터프라이즈 배포판도 해당 커밋이
백포트되어 있다면 영향을 받습니다. 안드로이드 쪽에서는 커널 6.6을 쓰는 Pixel 10 계열이 영향을
받는 것으로 확인됐고, 6.1 LTS 브랜치를 쓰는 Pixel 8 같은 이전 세대 기기는 영향권 밖입니다.

타임라인을 보면 2월에 비공개로 제보된 뒤, 첫 번째 패치 시도가 문제를 완전히 해결하지 못해 올바른
패치가 적용되기까지 약 두 달이 걸렸고(4월 24일), 이후 5월 30일 공개, 뒤이어 PoC 코드까지 공개되는
순서로 진행됐습니다. 패치가 공개 이전에 이미 배포됐기 때문에 실제 악용 사례는 보고되지 않았습니다.

주의사항

PoC가 이미 공개돼 있고 재현율도 높은 편이므로, v6.4 이상 커널을 쓰는 서버·데스크톱은 배포판 커널 업데이트를 우선순위로 적용해야 합니다.
패치 적용 여부는 커널 소스에서 epi_fget·__free(fput) 패턴이 들어갔는지로 확인할 수 있습니다.

grep -n 'epi_fget\|__free(fput)' /usr/src/kernels/$(uname -r)/fs/eventpoll.c

같은 2023년 커밋에서 함께 생긴 자매 취약점 CVE-2026-43074는 별도 패치로 수정됐으므로, Bad Epoll 패치를 적용했다고 해서 CVE-2026-43074까지 같이 막히는 것은 아닙니다. 두 CVE 모두 개별적으로 확인해야 합니다.
안드로이드 기기는 배포판 커널과 별도로 제조사·통신사 보안 업데이트 일정에 따라 패치 반영 시점이 달라지므로, 영향받는 기기라면 단말 제조사의 보안 패치 공지를 함께 확인하는 것이 안전합니다.

마무리

Bad Epoll은 흔히 쓰이는 I/O 서브시스템에 3년 가까이 잠복해 있던 로컬 권한상승 버그라는 점에서도
주의할 만하지만, AI 코드 감사가 같은 코드 구간에서 한 취약점은 잡아내고 다른 하나는 놓쳤다는 사실
자체가 지금 단계의 AI 기반 보안 감사 도구가 어디까지 신뢰할 수 있는지를 보여주는 사례이기도 합니다.
미세한 타이밍에 의존하는 멀티스레드 경쟁 조건은 여전히 사람이 직접 들여다봐야 하는 영역으로 남아있는
셈입니다. v6.4 이상 커널을 운영 중이라면 패치 적용 여부부터 확인하는 것이 우선입니다.