리눅스와 안드로이드를 루트 권한으로 탈취하는 ‘Use After Free’ 취약점인 ‘Bad Epoll’ 이해하기 (CVE-2026-46242)

요약

전체 버전으로 이동 ↓

내용: CVE-2026-46242로 추적되는 ‘Bad Epoll’은 리눅스 커널의 epoll 하위 시스템에서 발생하는 경합 조건(race condition) 기반의 use-after-free 취약점입니다. ep_remove() 정리 경로에서, 한 쪽의 close 경로는 파일의 epoll 링크를 지우고 이를 계속 사용하는 반면, 동시에 진행되는 파일 해제 작업은 지워진 링크를 감지하고 그 밑에 있는 기본 객체를 해제합니다. 권한이 없는 사용자가 이 비정상적인 쓰기 작업을 악용하여 루트 권한을 획득합니다.

영향: 권한이 없는 로컬 사용자가 레이스 조건을 성공적으로 유발하고, 크로스 캐시 공격을 통해 8바이트의 ‘use-after-free’ 쓰기 작업을 struct file에 대한 제어권 확보로 전환한 뒤, 임의의 커널 읽기 및 제어 흐름 탈취로 권한을 상승시켜 완전한 루트 권한을 획득합니다. 공개된 PoC(J-jaeyoung/bad-epoll, Google kernelCTF에 제출됨)에 따르면, AlmaLinux 10과 동일한 기반을 가진 6.12 커널에서 99%의 성공률을 보인다고 보고됩니다.

상태: 이 버그는 실제 존재하며, 이미 업스트림에서 수정되었습니다. 2월에 비공개로 보고되었고, 4월 24일에 수정되었으며, 5월 30일에 공개되었습니다. 수정 시점은 공개 시점보다 5주 앞서 있었으며, 실제 공격에 악용된 사례는 없습니다. 이 버그는 처음에는 커널CTF 0-day로 시작되었으나, 현재 방어 측 입장에서는 공개된 익스플로잇이 있는 N-day로 간주됩니다.

위험도: kernel.org와 NVD는 이 취약점에 CVSS 7.8 ‘높음’(AV:L/AC:L/PR:L) 등급을 부여했습니다. 레드햇은 약 6개의 명령어로 이루어진 경합 상황을 성공하기 어려운 것으로 간주하여 7.0으로 평가했습니다. 어느 쪽이든 결과적으로 루트 권한을 획득하게 되며, PoC의 약 99%에 달하는 성공률로 인해 이 좁은 시간 창은 이론적인 문제가 아닌 실질적인 문제가 됩니다.

이 문제가 중요한 이유: 노출된 시스템은 공유 호스팅, 멀티테넌트 호스트, CI 러너, 신뢰할 수 없는 코드가 실행되는 컨테이너 노드 등 로컬 격리가 핵심인 시스템들입니다. epoll은 거의 모든 서비스의 기반이 되므로, 비활성화할 수 있는 표면이 존재하지 않습니다. 여기서 로컬 LPE는 경계를 넘어서는 사건입니다.

지금 당장 다음 조치를 취하십시오: 이 문제를 해결할 수 있는 깔끔한 구성 방법은 없습니다. epoll을 비활성화할 수 없기 때문입니다. 신뢰할 수 없는 로컬 실행을 격리하고, 실패한 익스플로잇 실행 결과를 맹신하지 말고 커널에 실제로 수정 사항이 적용되었는지 확인하십시오. KernelCare의 재부팅 없이 적용 가능한 패치가 현재 분석 중이며, 아직 배포 채널에는 아무것도 올라오지 않았습니다. 자세한 내용은 아래를 참조하십시오.

이 티켓을 조기에 종결하고 싶은 유혹을 불러일으키는 두 가지 이유가 있는데, 둘 다 잘못된 생각입니다.

첫 번째는 PoC 자체의 README 문서로, 이 문서에는 해당 버그가 “v6.4 또는 그 이후 버전을 기반으로 한” 커널에만 영향을 미치며 v6.1 기반 커널은 안전하다고 명시되어 있습니다. CloudLinux 9 시스템(5.14 기반)에서 이 내용을 읽으면, 당연히 자신이 해당 범위에 포함되지 않는다고 판단할 것입니다. 하지만 이는 잘못된 생각입니다. 두 번째는 정상적으로 실행된 익스플로잇 사례입니다. 공개된 PoC를 소형 VM의 커널에 적용해 보면, 레이스 조건에서 수십만 번이나 패배하는 모습을 지켜보게 될 것입니다. 그러면 “재현 불가, 영향 없음”이라고 적고 넘어가기 쉽습니다. 이 역시 잘못된 판단이며, 특히 이 버그의 경우 매우 위험한 오판입니다.

Bad Epoll은 커널의 eventpoll 하위 시스템에서 발생하는 경합 조건형 ‘use-after-free’ 취약점입니다. 이 하위 시스템은 시스템 내의 거의 모든 네트워크 서비스가 의존하는 epoll 시스템 호출의 기반이 되는 메커니즘입니다. 이 경합 조건은 ep_remove() 정리 경로에서 발생하며, 취약점이 발현되는 시간 창은 대략 CPU 명령어 6개 분량입니다. 이 시간 창을 놓치면 아무 일도 일어나지 않습니다. 공개된 익스플로잇이 6.12 커널에서 높은 신뢰도로 이 조건을 성공적으로 공략하면, 권한이 없는 사용자도 루트 권한을 획득할 수 있게 됩니다.

EL10은 악용 가능함이 확인되었으며, EL9도 백포트된 도입 커밋을 통해 영향을 받을 가능성이 매우 높으므로, 이는 단순히 벤더 권고문을 신중하게 해석한 것이 아닙니다. 이는 실제 버그이며, 업스트림에서 수정 패치가 제공되었고, 이미 kernelCTF 제출물 중 하나에 무기화된 공개 익스플로잇이 포함되어 있습니다.

Epoll의 문제점

epoll은 struct eventpoll 객체, 다음을 기반으로 하는 struct file, 각 epoll 인스턴스에 대해. 이를 깔끔하게 해제하는 것이 중요한데, epoll 제거 경로와 백업 파일의 동시 해제라는 두 가지 경로가 거의 동시에 동일한 대상을 닫게 될 수 있기 때문이다.

이 버그는 해당 해제 과정에서 발생한 사소한 순서상의 오류입니다. ep_remove() 내부에서, 기존 코드는 파일의 epoll 연결을 해제했는데 (file->f_ep)를 누른 상태에서 file->f_lock, 그런 다음 크리티컬 섹션 내에서 그 파일과 해당 eventpoll 데이터를 계속 사용했습니다. 동시 실행되는 __fput() 해당 기간 내에 릴리스 패스트 패스를 호출하면 일시적인 NULL 값이 나타납니다 f_ep, epoll 정리 작업이 필요하지 않다고 판단하고, 곧바로 f_op->release. epoll-watches-epoll 방식에서 해당 경로는 감시 대상 리소스를 해제합니다. struct eventpoll 완전히. 첫 번째 경로는 여전히 실행 중이며, 그 다음 hlist_del_rcu() 방금 해제된 메모리에 삽입된 포인터를 통해 쓰기를 수행합니다.

[Unprivileged local process]
│  creates linked epoll objects backed by struct file
▼
[Two close paths race inside ep_remove()]
│  path A clears file->f_ep, keeps using the file
│  path B (__fput) sees NULL f_ep, skips epoll cleanup
▼
[Path B frees the watched struct eventpoll / recycles the file slot]
│  path A's hlist_del_rcu() writes into freed memory
▼
[Attacker-controlled 8-byte use-after-free write]
▼
[Cross-cache reclaim gives control of a struct file]
▼
[Arbitrary kernel read + control-flow hijack]
▼
[uid=0 root shell]

쓰기 작업 자체는 해제된 메모리의 8바이트 지점에 이루어지는데, 익스플로잇이 이를 어떻게 활용하는지 살펴보기 전까지는 별 문제 없을 것처럼 보입니다. 공개 체인은 두 쌍으로 구성된 네 개의 epoll 객체를 사용합니다. 한 쌍을 닫으면 경합 조건이 발생하고, 다른 한 쌍은 피해 대상이 됩니다. 이로 인해 8바이트 쓰기 작업이 struct file, 크로스 캐시 힙 회수 기법을 사용하여 해당 슬롯을 공격자가 제어하는 객체로 대체한 뒤, 임의의 커널 데이터 읽기 및 제어 흐름 탈취를 수행합니다.

레이스 조건이 매우 미묘하기 때문에 이 버그를 오판하기 쉬우며, 바로 그 때문에 수년 동안 발견되지 않았던 것입니다. 이 버그를 도입한 2023년 커밋에는 2026년 초에 발견되어 수정된 또 다른 레이스 조건인 CVE-2026-43074도 함께 포함되어 있었습니다. 하지만 그 수정 사항으로는 ‘Bad Epoll’ 버그가 해결되지 않았습니다. 올해 epoll 관련 수정 사항을 하나 적용했다고 해서 두 버그가 모두 해결되었다고 볼 수는 없습니다.

‘Upstream Fix’의 변경 사항

이 수정 사항은 규모가 작고 독립적이기 때문에 포팅이 원활하게 이루어집니다. 이 수정 사항은 ep_remove() 함수가 제거 대상 파일에 대한 보호되지 않은 참조를 사용할 때 정상적으로 작동하지 않도록 막아줍니다.

수정된 경로는 파일을 맨 앞에 고정하고, 다음을 참조로 삼아 epi_fget() 그리고 손에 struct file *file __free(fput) 닿기 전에 막아라 file->f_lock. 해당 참조가 유지되는 한, 파일의 참조 횟수는 0이 될 수 없으므로, __fput() 시작할 수 없으며, 동시 릴리스 경로는 정리 과정에서 파일이나 해당 eventpoll 객체를 해제할 수 없습니다. 핀을 해제할 수 없는 경우, ep_remove()는 지우기 작업을 수행하기 전에 중단됩니다. f_ep, 그리고 릴리스 경로는 경합 대신 eventpoll 뮤텍스를 통해 동기화되는 일반적이고 느린 정리 과정을 따릅니다.

개념적으로:

Before:  clear epoll link → keep using file → concurrent release frees it → write into freed memory
After:   pin file reference → do cleanup while pinned → concurrent release cannot free → release reference

이 한 가지 변경 사항만으로도 버그의 두 가지 측면, 즉 감시 대상의 해제 문제가 모두 해결됩니다. struct eventpoll, 그리고 ~의 재활용 struct file 슬롯인 반면, 원래 경로는 여전히 유효한 잠금을 보유하고 있다고 인식하고 있습니다.

누가 영향을 받나요?

CloudLinux 및 AlmaLinux 계열에 대한 간략한 답변: 9와 10 버전은 영향을 받는 것으로 확인되었으며, 8 버전은 문제가 없는 것으로 예상됩니다.

영향을 받는 대상:

• CloudLinux 10 / AlmaLinux 10 (6.12 기반): 공개된 PoC의 ‘충돌 전용’ 변종은 베어 메탈 환경의 권한이 없는 AlmaLinux 10 호스트를 몇 초 만에 확실하게 패닉 상태로 만듭니다. 이는 실험실 수준의 호기심 대상이 아닌, 실제로 악용 가능한 ‘use-after-free’ 취약점입니다. 이는 업스트림에서 완전한 익스플로잇이 99%의 신뢰도로 루트 권한을 획득하는 것과 동일한 6.12 기반입니다.
• CloudLinux 9 / AlmaLinux 9 (5.14 기반): 백포트된 도입 커밋을 통해 영향을 받을 가능성이 높음 – Red Hat은 해당 도입 커밋이 해당 라인으로 백포트되었기 때문에 RHEL 9를 ‘영향을 받는 버전’으로 분류하고 있습니다. 5.14 라인에서의 재현 여부는 아직 확인 중이므로, 내부에서 입증된 사항이라기보다는 확인이 완료될 때까지 ‘영향을 받는 것으로 간주’해야 합니다.

영향을 받지 않을 것으로 예상되나, 이를 신뢰하기 전에 반드시 확인하십시오:

• CloudLinux 8 / AlmaLinux 8 (4.18 기반): 레드햇(Red Hat)은 RHEL 7 및 8이 해당 취약점의 영향을 받지 않는다고 밝혔으며, CL8도 이를 상속받아 문제가 없을 것으로 예상됩니다. 감사관이나 고객이 확실한 확인을 요구할 경우, 단정적으로 말하기보다는 출처를 직접 확인하시기 바랍니다.

버전 창이 첫 번째 함정입니다. PoC의 README 파일에는 v6.4 이상 메인라인 버전이 해당된다고 명시되어 있으며, v6.1 기반 커널은 안전하다고 밝히고 있습니다. 이는 메인라인의 경우 사실이지만, 엔터프라이즈 리눅스(EL)에는 무의미합니다. 벤더들이 해당 변경 사항을 훨씬 오래된 버전 라인으로 백포트하기 때문입니다. 5.14 기반 EL9 커널은 v6.4보다 훨씬 낮은 버전에 해당하지만, 여전히 이 문제의 영향을 받습니다. 업스트림 버전을 기준으로 EL 시스템의 상황을 판단해서는 안 됩니다.

재현에 실패하는 것이 두 번째 함정입니다. 경합 현상은 코어 수, 스케줄링, 힙 레이아웃, 빌드 구성에 극도로 민감합니다. 작은 2vCPU 가상 머신에서 초기 테스트를 진행했을 때는 경합이 전혀 발생하지 않아 문제가 없는 것처럼 보였지만, 멀티코어 베어 메탈 환경에서 더 강력한 재현 도구를 사용하자 같은 커널 라인에서 몇 초 만에 패닉이 발생했습니다. 문제는 테스트 환경이 불량했던 것이지, 패치된 커널 때문이 아니었습니다. 경합이 발생하지 않았다고 해서 안전하다고 단정해서는 안 됩니다.

그러니 익스플로잇이 아니라 소스 코드를 기준으로 확인해 보세요. 업스트림 커밋 해시를 grep으로 검색하는 것은 오해의 소지가 있습니다. 백포트 과정에서 해시가 제거되기 때문입니다. 대신 ep_remove() 내부의 수정 패턴을 확인해 보세요:

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

ep_remove()가 파일을 epi_fget() 그리고 한 __free(fput) 만지기 전에 주의하세요 file->f_lock, 패치가 적용되어 있습니다. 만약 해당 항목이 없다면, 커널에 패치가 적용되지 않은 것이며, 이 커널에서 실행된 모든 부정적 익스플로잇은 오탐이었습니다.

지금 바로 위험을 줄이세요

솔직히 말해서, 이 문제를 해결할 수 있는 깔끔한 구성 방법은 없습니다.

epoll은 핵심 시스템 호출 인터페이스입니다. nginx, php-fpm, mysqld, systemd 등 프로덕션 호스트에 있는 거의 모든 것이 이를 기반으로 하며, 모든 범용 커널에서 활성화되어 있습니다. 서버 운영에 필요한 워크로드를 중단시키지 않으면서도 취약한 경로를 차단할 수 있는 sysctl 설정도, 블랙리스트에 추가할 모듈도, 제거해야 할 권한도 없습니다. 사용자 네임스페이스나 특별한 권한조차 필요하지 않습니다. 연구원에 따르면 브라우저 렌더러 샌드박스를 포함한 제한된 환경에서도 epoll에 접근할 수 있다고 합니다. 이에 대해 한 줄짜리 epoll 강화 방법을 제시하는 사람은 누구든, 결함이 있는 시스템을 판매하는 것이나 다름없습니다.

이 버그는 로컬 환경에서만 발생하기 때문에(AV:L, PR:L), 효과적인 대응책은 여러분이 이미 잘 알고 있는 지루한 방법들뿐입니다:

• 이 버그는 로컬에서 권한이 없는 진입점을 필요로 하므로, 영향을 받는 호스트에서 코드를 실행할 수 있는 사용자를 제한하십시오. 진입점이 적을수록 노출 위험도 줄어듭니다.
• 신뢰할 수 없거나 부분적으로만 신뢰할 수 있는 로컬 실행(고객 코드, CI 작업, 빌드 단계 등)을 가장 보호해야 할 호스트에서 분리하거나, 우선적으로 수정할 수 있는 커널로 이동시키십시오.
• 로컬 격리가 실질적인 보안 경계인 호스트를 우선순위로 삼으십시오: 공유 호스팅, 멀티테넌트 노드, CI 러너, 컨테이너 호스트.
• 익스플로잇이 아무런 오류 메시지 없이 실행된다고 해서 안전하다고 추측하기보다는, 앞서 설명한 소스 코드 확인 절차를 통해 커널에 수정 사항이 반영되었는지 확인하십시오.

결정적인 순간입니다. 호스트가 신뢰할 수 없는 로컬 코드를 실행하지 않고, 소수의 신뢰할 수 있는 사용자 그룹만 있는 경우, 잔여 위험은 낮으므로 에라타나 재부팅이 필요 없는 패치가 출시되면 평소와 같은 주기로 패치를 적용하면 됩니다. 호스트가 공유 호스팅, CI, 멀티테넌트와 같이 관리할 수 없는 코드를 실행하는 경우, 해당 호스트를 당장 취약한 상태로 간주하고, 재부팅이 필요 없는 패치나 수정된 커널이 출시되는 즉시 이를 우선적으로 적용해야 합니다.

재부팅 없는 패치 적용

바로 이런 종류의 버그를 해결하기 위해 재부팅 없이 패치를 적용하는 방식이 존재합니다. 업스트림의 변경 사항은 이미 제공되고 있지만, 이는 실행 중인 시스템을 보호해 주지는 않습니다. 공급업체가 해당 변경 사항을 백포트해야 하고, 사용자가 패키지를 설치해야 하며, 시스템이 새로운 커널로 부팅되어야 하기 때문입니다. 바로 이 마지막 단계에서 보안 취약성이 여전히 남아 있으며, 가장 중요한 부분일수록 해결하기가 가장 어렵습니다.

이 수정 사항은 소규모의 독립적인 정리 수정 사항으로, 재부팅 없이 적용할 수 있는 패치로 적합합니다. 이 패치는 업스트림의 ep_remove() 참조 핀을 그대로 백포트하여 실행 중인 커널에 적용한 것으로, 이로 인해 진행 중인 정리 작업이 더 이상 해당 파일의 메모리를 해제할 수 없게 됩니다. 이는 업스트림 수정 사항과 동일한 보장을 제공하면서도 재부팅 없이 적용됩니다.

CloudLinux 및 AlmaLinux의 경우, 수정 방법이 확인되었습니다. 이는 업스트림의 ep_remove() 참조 핀(RHEL 10 백포트, gerrit 257974)을 그대로 백포트하는 방식입니다. KernelCare 백포트는 아직 분석 중이며, EL10 및 EL9에서의 재현 여부가 검증되고 있으므로, 아직 검증 완료된 패치는 없으며 테스트, 메인 또는 ePortal 피드에도 올라온 패치가 없습니다. LibCare는 이번 범위에 포함되지 않습니다. 이는 커널 전용 버그이므로, 패치할 사용자 공간 라이브러리 관련 부분은 없습니다.

릴리스가 제공되면, 테스트 채널(피드)을 통해 이를 배포하는 절차는 다음과 같습니다:

kcarectl --update --prefix test

실행 중인 패치 빌드의 날짜가 릴리스 날짜와 같거나 그 이후인지 확인하려면:

kcarectl --info | grep kpatch-build-time

빌드 날짜만으로는 아무것도 증명할 수 없습니다. CVE 매핑, 공급업체 정정 공지, 소스 패턴 또는 KernelCare 패치 상태를 직접 확인하십시오.

KernelCare 다운로드 →

탐지

Bad Epoll은 디스크에 뚜렷한 흔적을 남기지 않습니다. 이 익스플로잇은 전적으로 커널 메모리 내에서 작동합니다(레이스 조건 유발, 해제된 객체 손상, 제어 흐름 재작성 등). 따라서 파일 무결성 검사 도구는 이를 탐지할 수 없습니다. 트리거는 모든 리눅스 호스트에서 일반적으로 사용되는 표준 인터페이스(epoll 인스턴스 생성, 디스크립터 및 타이머 파일 descriptor 등록, 종료 등)를 기반으로 구성됩니다. 이로 인해 탐지는 행동 기반 분석 영역으로 넘어가게 되며, 다음의 각 항목은 단서일 뿐, 확실한 증거는 아닙니다:

• 권한이 없는 프로세스가 좁은 경합 상황을 지속적으로 유발하는 것과 일치하게, 촘촘한 루프 내에서 대량의 epoll 인스턴스와 timerfd를 생성하고 해제하고 있다.
• eventpoll 해제 경로에서 발생하는 커널 오오프(oops) 또는 리스트 손상 버그, 관련 시그니처는 다음과 같습니다. ep_show_fdinfo, ep_clear_and_put, ep_eventpoll_release또는 __fput.
• 하드웨어나 설정 변경과 같은 명백한 원인이 없음에도 불구하고 멀티코어 호스트에서 커널 패닉과 재부팅이 반복적으로 발생하며, ‘충돌 전용’ 트리거만으로도 몇 초 만에 시스템이 패닉 상태에 빠집니다.
• 위와 같은 활동이 집중적으로 발생한 직후, 이에 상응하는 sudo 또는 로그인 이벤트 없이 로컬 사용자나 서비스 계정이 권한을 획득하는 경우.

만약 노출된 EL9 또는 EL10 호스트에서 신뢰할 수 없거나 부분적으로만 신뢰할 수 있는 로컬 코드가 실행되었고, epoll 종료 경로에서 커널 불안정 현상이 집중적으로 발생하는 경우, 파일 해시가 정상이라고 해서 시스템이 침해되지 않았다고 단정 짓기보다는 패치 적용을 최우선으로 하고, 해당 호스트를 면밀히 조사해야 할 대상으로 간주해야 합니다. 즉, 새로운 계정이나 SSH 키, 변경된 인증 설정, 예상치 못한 서비스 등이 있는지 확인해야 합니다.

이 주제가 중요한 이유

‘Bad Epoll’은 원격 코드 실행이 아닙니다. 이 취약점을 이용해 인터넷을 통해 서버에 루트 권한을 얻는 일은 없습니다. 하지만 실제로 이 취약점이 발생하는 환경에서는 그나마 위안이 될 뿐입니다.

공유 호스팅은 고객의 코드를 실행합니다. CI 러너는 가장 최근의 풀 리퀘스트에서 지시한 내용을 그대로 실행합니다. 컨테이너와 쿠버네티스 노드는 다양한 신뢰 수준에서 워크로드를 실행하며, 멀티테넌트 호스트는 테넌트 간 격리를 위해 특별히 존재합니다. 이 모든 환경에서 로컬 권한 상승은 전체 설계가 방지하고자 하는 사건입니다. 이는 실행이 허용되었던 코드를, 절대 실행되어서는 안 되는 루트 권한으로 실행되는 코드로 변환시킵니다. 이 버그가 브라우저 렌더러 샌드박스처럼 대부분의 커널 버그가 접근할 수 없는 곳에서도 접근 가능하다는 점은 공격 표면을 더욱 넓힐 뿐입니다.

이 문제를 오해하기 쉬운 이유는 바로 그것이 위험한 이유와 같습니다. 세 가지 그럴듯한 신호가 모두 “안전”을 가리키지만, 모두 오해의 소지가 있습니다. “v6.4+” 버전 표기는 5.14 기반 EL9로의 백포트를 무시하고, 실패한 익스플로잇 실행은 6개 명령어 레이스 조건을 별다른 노력 없이 트리거하기가 얼마나 어려운지를 간과하며, 올해 초에 적용된 동종 epoll 수정 사항은 이번 문제 해결에 아무런 도움이 되지 않습니다. 이 중 어느 하나라도 신뢰한다면, 취약한 호스트를 ‘안전’한 것으로 분류하게 될 것입니다.

위험은 언제나 그렇듯 특정 곳에 집중됩니다. 업데이트가 몇 개 뒤처진 서버, 아무도 재부팅하지 않는 오래 운영된 CI 실행 서버, 유지보수 시간대를 협상해야 하는 멀티테넌트 호스트 등이 바로 그곳입니다. 공개된 PoC가 있는 N-day 취약점이 조용히 당일 문제로 번지는 곳은 바로 이러한 호스트들이며, 재부팅 없이 적용 가능한 패치의 유무가 오늘 해결할 수 있을지 아니면 다음 분기에나 해결할 수 있을지를 가르는 결정적인 요소가 되는 곳이기도 합니다.

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

• CloudLinux 9와 CloudLinux 10을 모두 영향을 받는 것으로 간주하고 확인된 것으로 처리하십시오. “v6.4+”라는 주석을 근거로 CL9를 예외로 두지 마십시오. 해당 기능을 도입한 커밋은 5.14 계열로 백포트되었기 때문입니다.
• 각 커널은 익스플로잇 결과로 판단하지 말고 소스 코드를 통해 확인하십시오: ep_remove() 함수에서 epi_fget() + __free(fput) 패턴을 수정하고, 실패한 PoC 실행을 ‘결론이 나지 않은’ 것으로 간주한다.
• “올해 epoll 버그를 수정했다”는 사실만으로는 이 문제가 해결되었다고 가정하지 마십시오. 관련 CVE-2026-43074에 대한 수정 사항만으로는 ‘Bad Epoll’ 문제가 해결되지 않습니다.
• 로컬 격리가 보안 경계 역할을 하는 호스트를 우선적으로 고려하십시오: 공유 호스팅, 멀티테넌트 노드, CI 러너, 신뢰할 수 없는 코드가 실행되는 컨테이너 및 개발용 호스트 등입니다.
• 수정 조치가 적용될 때까지 신뢰할 수 없는 로컬 실행을 최소화하고 격리하십시오. 의존할 수 있는 구성상의 완화책은 없습니다. epoll을 비활성화할 수 없기 때문입니다.
• CloudLinux 8이 안전하다고 다른 사람에게 알리기 전에, 원본에서 직접 확인해 보십시오.
• eventpoll 해제 경로에서 원인을 알 수 없는 커널 패닉과 비정상적인 epoll/timerfd 활동을 찾아내고, 파일 해시가 정상이라고 해서 이를 충분한 증거로 간주하지 마십시오.
• KernelCare 재부팅 불필요 패치가 검증되어 피드에 반영되는 대로, 특히 재부팅이 가장 어려운 호스트에 우선적으로 적용하십시오. 해당 패치는 아직 분석 중이며, 릴리스가 완료되면 K-태그가 이곳에 게시될 예정입니다.

모든 커널에 패치를 적용할 수 있으며, 재부팅이 필요하지 않습니다. 아직 KernelCare를 사용하지 않으신 분이라면, 지금이 바로 재부팅 없이 패치를 적용하는 방식이 긴급 유지보수 시간이나 가동 중단 없이 중요한 리눅스 시스템을 어떻게 보호하는지 확인해 볼 좋은 기회입니다.

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

참조

• Red Hat CVE-2026-46242 – https://access.redhat.com/security/cve/cve-2026-46242
• NVD CVE-2026-46242 (kernel.org CNA, CVSS 3.1 7.8) – https://nvd.nist.gov/vuln/detail/CVE-2026-46242
• linux-cve-announce – https://lore.kernel.org/linux-cve-announce/
• 공개 PoC 및 근본 원인 분석 보고서 (정재영, Google kernelCTF) – https://github.com/J-jaeyoung/bad-epoll
• 상류 수정 커밋 a6dc643c6931 (2026-04-24); 버그를 유발한 커밋 58c9b016e128 (2023-04-08, 메인라인 v6.4)
• 관련된 자매 버그 CVE-2026-43074 (동일한 도입 커밋, 별도로 수정됨)