PwnEscape, 18년 동안 커널 네트워크 스택에 숨어 있었다

요약

개요: 연구자가 ‘PwnEscape’라고 명명한 CVE-2026-99999는 리눅스 커널이 오프로드 메타데이터가 첨부된 패킷에 대해 IPv4 체크섬을 처리하는 방식에 존재하는 결함입니다. 게스트 VM은 호스트가 커널이 이미 유효성을 검증한 IPv4 헤더에 2바이트를 기록하도록 만드는 체크섬 오프로드 메타데이터를 제공할 수 있습니다. 커널 CNA는 2026년 10월 15일에 이 결함을 공개했습니다.

영향: 게스트가 전송하는 패킷을 통해 호스트의 메모리가 유출되며, Vercel은 해당 취약점이 자사의 프로덕션 샌드박스에서 시연되었다고 밝혔습니다. 또한 연구원은 호스트를 다운시키고 루트 권한으로 코드를 실행하기도 했으나, 이는 Vercel의 환경과 동일하게 구축된 자체 KVM 및 Firecracker 머신에서만 가능했습니다.

위험도: 커널 CNA는 이 취약점을 CVSS 3.1 기준 9.3점의 ‘Critical’ 등급으로 평가했으며, 로컬 공격 경로를 가지며 적용 범위가 변경되었습니다. 하지만 멀티테넌트 호스트의 경우, ‘로컬’이란 고객이 임대한 가상 머신을 의미할 수 있으며, 이로 인한 피해는 그 아래에 있는 호스트에 미치게 됩니다.

영향을 받는 대상: 이 취약한 코드는 2008년 출시된 리눅스 2.6.27 버전으로 거슬러 올라갑니다. RHEL, AlmaLinux, Rocky Linux, Oracle Linux, CloudLinux를 포함한 EL7부터 EL10까지의 엔터프라이즈 리눅스 커널이 영향을 받을 것으로 예상되나, 개별 커널 트리에 대한 검증은 아직 이루어지지 않았습니다. 관리자가 통제하지 못하는 게스트를 실행 중인 호스트와, 신뢰할 수 없는 사용자가 셸을 보유하고 있는 공유 서버가 가장 먼저 위험에 노출됩니다. EL8부터 EL10까지는 /dev/kvm이 기본적으로 모든 사용자에게 쓰기 권한이 부여되어 있으므로, 해당 사용자들은 자체 VM을 부팅하여 이를 통해 호스트를 공격할 수 있습니다.

현황: 이 수정 사항은 10월 14일에 메인라인에 반영되었으며, 10월 15일에는 7개의 업스트림 안정판 커널에 이 수정 사항이 포함되어 출시되었습니다. 10월 16일 현재, 이 수정 사항을 적용한 배포판 커널은 없습니다. 공개된 익스플로잇 코드는 없으며, 실제 환경에서 악용된 사례도 보고되지 않았습니다. 이는 제로데이 취약점이 아닌, 사전 조율된 공개 사례입니다.

지금 당장 다음 조치를 취하십시오. 신뢰할 수 없는 게스트를 실행하는 호스트에서는 해당 게스트의 virtio-net 인터페이스에서 체크섬 오프로드를 비활성화하고, 이로 인한 처리량 저하를 감수하십시오. 이 설정은 로컬 사용자가 직접 시작하는 VM에는 영향을 미치지 않으므로, 신뢰할 수 없는 셸 사용자가 있는 호스트에서는 비특권 사용자 네임스페이스도 비활성화하십시오. 커널을 직접 빌드하는 경우, 고정된 업스트림 안정 버전을 사용하도록 전환하십시오.

libvirt 호스트에서 게스트의 정의에 명시적인 체크섬 설정이 있는지 확인하십시오:

virsh dumpxml <domain> | grep ‘csum=’

이러한 속성은 누군가가 직접 설정한 경우에만 XML에 나타납니다. virtio 인터페이스의 경우, 출력이 비어 있으면 QEMU의 기본값이 적용된다는 뜻이며, 이 기본값에서는 체크섬 오프로드가 활성화된 상태로 유지됩니다.

자세한 내용

다중 테넌트 VM 호스팅은 한 가지 약속을 기반으로 합니다. 고객이 게스트 내에서 실행하는 모든 것은 게스트 내부에만 머무릅니다. PwnEscape는 호스트 커널이 자체적으로 수행하는 2바이트 쓰기 작업을 통해 이 약속을 깨뜨립니다.

이 버그가 특이한 점은 발생 위치입니다. KVM에 있는 것이 아니며, 올해 초 발견된 Januscape 및 Zapscape와 달리 중첩 가상화가 필요하지 않습니다. 이 버그는 호스트의 일반적인 IPv4 출력 경로에 존재합니다. 게스트는 초당 수천 번씩 수행하는 것과 동일한 방식으로, 즉 호스트에게 체크섬 계산을 완료해 달라고 요청함으로써 해당 경로에 도달하게 됩니다.

이 수정 사항은 업스트림에 반영되었으나 배포판 커널에는 아직 반영되지 않은 상태이며, CVE와 함께 자세한 설명 문서가 공개되었습니다. 이 두 가지가 동기화될 때까지는 호스트가 취약한 상태에 놓이게 됩니다.

이번 주에 실제로 무슨 일이 있었을까

pwn.ai의 파울로스 이벨로(Paulos Yibelo)는 Vercel Sandbox 100만 달러 챌린지 3일 차에 이 버그를 발견했습니다. 그는 9월 4일 커널 보안 담당자 및 네트워킹 유지보수 담당자들에게 근본 원인을 비공개로 보고했으며, 3일 후 레드햇(Red Hat)의 마이클 S. 치르킨(Michael S. Tsirkin)이 해당 버그를 재현했습니다.

이 패치 시리즈는 9월 19일 netdev에 공개되었습니다. Tsirkin의 보다 국소적인 수정 사항인 커밋 6785011f8b16은 10월 8일 네트워킹 트리에 적용되었으며, Vercel이 챌린지 결과를 발표한 당일인 10월 14일에 메인라인에 병합되었습니다. CVE, 7개의 안정판 커널, 그리고 연구원의 기술 보고서인 ‘PwnEscape: Guest-to-Host KVM Escape’는 모두 10월 15일에 공개되었습니다. 이 기술 보고서는 버그에 대해 상세히 설명하고 있지만, 익스플로잇 코드는 포함되어 있지 않습니다.

두 바이트가 어떻게 호스트 메모리 누수로 이어지는가

TAP, vhost-net 또는 AF_PACKET을 통해 들어오는 패킷은 발신자가 보낸 작은 크기의 오프로드 힌트 블록인 virtio_net_hdr을 포함할 수 있습니다. 이 힌트 중 csum_start와 csum_offset이라는 두 가지는 커널에 체크섬 영역이 시작되는 위치와 결과를 저장할 위치를 알려주며, 패킷에는 CHECKSUM_PARTIAL 플래그가 설정되어 다운스트림에서 해당 작업을 완료할 수 있도록 합니다.

취약점은 입력 검증 단계에 있습니다. virtio_net_hdr_to_skb() 함수는 csum_start가 버퍼 내 20바이트 지점 이상에 위치하는지 여부만 확인합니다. TAP의 경우, 해당 버퍼는 14바이트 길이의 이더넷 헤더로 시작하므로, 20바이트 지점은 정확히 IPv4 헤더 내부에 위치하게 됩니다. csum_start를 IP 헤더의 끝 부분과 비교하는 코드는 없습니다.

호스트가 패킷을 조각내야 할 때, ip_do_fragment()는 skb_checksum_help()를 호출하며, 이 함수는 체크섬을 계산하여 csum_start + csum_offset 위치에 2바이트를 기록합니다. 게스트는 체크섬 계산 대상 데이터를 제공하므로, 사실상 이 2바이트를 제어하게 됩니다. 이 기록 작업은 패킷 버퍼를 벗어나지 않습니다. 이 데이터는 커널이 이미 분석하고, 라우팅하며, 신뢰한 IP 헤더에 기록됩니다.

그런 다음 프래그멘터는 해당 헤더를 다시 읽습니다. 연구자의 경우, 첫 번째 바이트가 0x45에서 0x4f로 바뀌었는데, 여전히 IPv4였지만 헤더 길이 필드(ihl)는 20바이트 대신 60바이트로 표시되었습니다. ip_frag_next()는 이만큼의 헤더 바이트를 모든 프래그먼트에 복사합니다. 패킷의 유효한 선형 데이터는 28바이트(헤더 20바이트, 페이로드 8바이트)에 불과했기 때문에, 각 복사본의 마지막 32바이트는 패킷 끝을 넘어선 호스트 메모리에서 가져온 것이었습니다. 이 데이터는 전송된 조각들 내에서 IPv4 옵션 형태로 호스트를 떠나며, 공격자가 제어하는 수신자라면 누구나 이를 읽을 수 있습니다.

32바이트는 그리 많은 양은 아니지만, 게스트가 계속 데이터를 전송하는 한 이 정보 유출은 반복됩니다. 연구원은 이를 힙 그루밍 기법과 결합하여 호스트 커널 메모리에 선택된 64바이트 데이터를 쓰도록 한 뒤, 실험실에서 네 차례에 걸쳐 콜드 부팅을 수행하며 호스트에서 루트 권한으로 헬퍼 프로그램을 실행했습니다. 이 공격 체인은 공개되지 않았으며, TuxCare는 이 중 어떤 것도 재현하지 못했습니다.

9.3점의 의미

벡터는 AV:L/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H이며, 특히 AV:L 부분이 사람들을 헷갈리게 합니다.

중요한 것은 변경된 영향 범위입니다. 공격자는 ‘게스트’라는 하나의 보안 도메인에 위치해 있지만, 피해는 ‘호스트’라는 다른 보안 도메인에서 발생합니다. 이것이 바로 CVSS 영향 범위가 표현하고자 하는 상황이며, 로컬 취약점이 9.3점을 받은 이유이기도 합니다. 이 글을 작성하는 시점에서 NVD는 자체 분석 결과를 공개하지 않았기 때문에, 현재로서는 CNA 점수만이 유일한 평가 기준입니다.

적어도 한 곳의 취약점 데이터베이스에서는 이미 이 문제를 원격으로 악용 가능한 것으로 분류하고 있습니다. 하지만 이 문제 자체만으로는 원격 악용이 불가능합니다. CHECKSUM_PARTIAL과 csum_start는 패킷 내의 바이트가 아니라 커널의 패킷 버퍼에 있는 메타데이터입니다. 네트워크 카드는 수신된 데이터로부터 이 값들을 설정하지 않습니다. GRO는 이 값들을 설정할 수 있지만, 커널이 직접 파싱한 TCP 헤더를 통해서만 가능하며, IP 옵션이 없는 IPv4 패킷에 대해서만 가능합니다. 인터넷에서 전송된 조작된 패킷은 해당 영역에 도달할 수 없습니다.

원격 공격자는 먼저 게스트, 컨테이너 또는 로컬 계정에서 발판을 마련해야 합니다. 멀티테넌트 VM 호스트에서는 이러한 발판을 마련하는 데 신용카드 한 장이 필요합니다.

누가 그 벌레를 잡을 수 있을까?

주요 시나리오는 신뢰할 수 없는 VM 게스트가 TAP 또는 vhost-net을 통해 호스트에 접근하는 것으로, KVM 및 Firecracker 환경 모두에서 시연됩니다. VMM이 이미 TAP 파일 설명자를 보유하고 있으며 오프로드 메타데이터를 변경 없이 그대로 전달하기 때문에, 게스트는 호스트 장치에 대한 액세스 권한이 필요하지 않습니다.

로컬 경로의 경우 불확실성이 더 큽니다. 사용자 네임스페이스 내에서, 권한이 없는 프로세스도 IFF_VNET_HDR을 사용하여 tun을 열 수 있을 수 있습니다. tun은 해당 네임스페이스 내에서만 CAP_NET_ADMIN을 확인하며, 해당 네임스페이스에서는 프로세스가 이 권한을 보유하고 있기 때문입니다. PACKET_VNET_HDR을 사용하는 AF_PACKET도 비슷한 경우인데, 이는 CAP_NET_RAW가 필요하며 사용자 네임스페이스에서도 이 권한을 부여하기 때문입니다. 두 경우 모두 재현되지는 않았습니다. EL8 및 이후 버전에서 기본적으로 활성화된 비특권 사용자 네임스페이스는 여기서 주요 취약 요인이지만 유일한 요인은 아닙니다. 기존 macvtap 또는 ipvtap 장치에 대한 접근은 별도의 경로로, 이에 대한 고유한 권한 요구 사항이 적용됩니다. 사용자가 직접 부팅하는 가상 머신(VM)도 마찬가지입니다. EL8부터 EL10까지의 경우, 기본 udev 규칙에 따라 /dev/kvm은 모든 사용자가 쓰기 권한을 갖도록 설정되어 있으므로, 어떤 로컬 사용자라도 이를 시작하고 그 안에서 루트 권한을 가질 수 있습니다. 해당 VM이 (일반적으로 사용자 네임스페이스를 통해) TAP 또는 vhost-net 백엔드를 할당받으면, 고객 게스트가 하는 것과 동일한 조작된 오프로드 메타데이터를 호스트에 전달할 수 있습니다. 공유 호스팅 서버의 경우, 고객 VM을 실행한 적이 없더라도 이 문제의 적용 범위에 포함됩니다.

루트리스 컨테이너에서 고객 코드를 빌드하는 공유 CI 러너는, 로컬 경로에 대한 테스트가 여전히 필요하긴 하지만, 그런 이유로 한 번 살펴볼 만합니다.

사용자가 제어할 수 없는 게스트를 실행하는 호스트와 신뢰할 수 없는 사용자에게 셸을 제공하는 공유 서버가 우선적으로 처리되며, 그 다음으로 신뢰할 수 없는 코드를 실행하는 다른 시스템이 처리됩니다. 그 외의 모든 시스템은 알려진 노출 위험이 낮으므로, 실제 위험 수준에 맞춰 정기적인 보안 패치 과정을 통해 수정 조치를 적용하면 됩니다.

PwnEscape는 제로데이 취약점인가요?

Vercel의 게시글에 따르면 이는 리눅스 커널 제로데이 취약점으로, 지난 8월 Yibelo가 이를 발견했을 당시 업스트림 측에서는 그 존재를 전혀 알지 못했습니다. 하지만 CVE-2026-99999가 공개되었을 때쯤에는 이미 메인라인에 수정 패치가 반영된 상태였습니다. 현재 이 사안에 대응하고 있는 모든 분들께 말씀드리자면, 이는 수정 패치가 제공되고, 공개된 익스플로잇 코드가 없으며, 승인된 연구 목적 외의 악용 사례가 보고되지 않은 상태에서 이루어진 조정된 공개 사례입니다.

이 연구원은 취약한 하이퍼바이저 구성에 대한 공격 코드가 몇 주 내로, 기본 설정의 하이퍼바이저 구성에 대한 공격 코드는 한 달도 채 되지 않아 등장할 것이라고 예측합니다. 이를 연구원의 전망으로 받아들이시기 바랍니다. 취약점에 노출된 호스트는 이 예측이 적중할지 지켜보기만 해서는 안 됩니다.

영향을 받는 대상은 누구인가요?

2026년 10월 16일 기준 벤더 커널 현황(KernelCare의 재부팅 없이 적용 가능한 패치 현황과는 별개):

uname -r 명령어로 배포판 상태를 판단하지 마십시오. 엔터프라이즈 커널은 기본 버전을 변경하지 않고 수정 사항을 역포트하므로, 5.10.272보다 오래된 것으로 보이는 EL 커널이라고 해서 어떤 식으로든 이를 입증할 수는 없습니다. 해당 커널에 대한 공급업체 공지나 검증된 재부팅 불필요 패치만이 이를 확정지을 수 있습니다.

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

수정 사항이 적용될 때까지 필수 조건을 비활성화하기

아래의 각 옵션은 필수 전제 조건 중 하나를 제거합니다. TuxCare에서는 아직 이 옵션들을 테스트하지 않았으므로, 우선 중요하지 않은 게스트에서 시도해 보시기 바랍니다.

VM 호스트의 경우 중요한 점은 신뢰할 수 없는 게스트에 체크섬 오프로드를 제공하지 않는 것입니다. QEMU를 직접 사용하는 경우, 장치에서 다음과 같이 설정하십시오:

-device virtio-net-pci,netdev=n0,csum=off,guest_csum=off

With libvirt, add <driver><host csum=’off’/><guest csum=’off’/></driver> inside the guest’s <interface> element. Either way it’s per VM, needs a full guest restart, and costs throughput because the guest loses TSO and GSO. Firecracker is the awkward case. It was one of the demonstrated targets, and whether offload can be switched off per VM there hasn’t been verified yet.

로컬 경로의 경우에만, 권한이 없는 사용자 네임스페이스를 비활성화하십시오. 먼저 sysctl user.max_user_namespaces 명령을 사용하여 현재 값을 확인한 다음, 다음 명령을 실행하십시오:

sysctl -w user.max_user_namespaces=0

이렇게 하면 새로운 사용자 네임스페이스는 차단되지만 기존 네임스페이스는 영향을 받지 않습니다. 이 설정을 영구적으로 적용하려면 /etc/sysctl.d/ 아래의 파일에 해당 설정을 저장하고, 해당 파일을 삭제하고 이전 값으로 되돌리면 설정을 원상복구할 수 있습니다. 이 설정은 실질적인 단점이 있습니다. 루트리스 컨테이너와 Chrome 및 Flatpak 샌드박스가 작동하지 않게 되며, 게스트 탈출 경로에는 아무런 영향도 미치지 않습니다. 신뢰할 수 있는 계정만 가상 머신을 실행해야 하는 경우, /dev/kvm의 권한을 kvm 그룹에 대해 0660으로 설정하는 udev 규칙을 적용하면 자체 가상 머신 경로는 차단되지만, 직접적인 tun 경로는 차단되지 않습니다.

실행 중인 커널 패치 및 검증

커널을 직접 빌드하는 경우, 표에 나열된 수정된 안정 버전 중 하나로 전환하십시오. 해당 버전을 설치해도 호스트가 해당 커널로 부팅하기 전까지는 아무것도 변경되지 않으므로, 실제로 어떤 커널이 실행 중인지 확인하십시오:

uname -r

새로운 커널을 설치한 후 한 번도 재부팅하지 않은 호스트는 여전히 취약점이 있는 커널을 실행 중이며, 특히 하이퍼바이저가 가장 심각한 문제입니다.

커널용으로 릴리스되면, KernelCare 재부팅 불필요 패치는 재부팅 없이도 수정 사항을 적용할 수 있습니다. 자동 업데이트가 활성화된 경우, 해당 패치는 실행 중인 커널의 피드에 포함되는 즉시 적용되며, kcarectl –update 명령을 통해 필요 시 요청할 수 있습니다. 적용 범위를 확인하려면:

kcarectl –patch-info | grep ‘CVE-2026-99999’

현재 대부분의 스트림에 대해 재부팅 없이 적용 가능한 패치가 배포 중입니다(위의 상태 참조). 따라서 해당 패치가 적용되면 명령어를 실행했을 때 실행 중인 커널의 CVE가 표시될 것이며, 표시될 때까지는 완화 조치를 계속 유지해 주십시오.

그리고 후속 조치도 있습니다. 업스트림 수정 내용은 소규모로, 6개의 파일에 걸쳐 44줄이 추가되고 12줄이 삭제되었습니다. 이 수정에서는 csum_start가 IP 헤더 끝보다 앞을 가리키는 패킷을 거부하는 헬퍼 함수인 ip_check_csum_start()를 추가하고, IP 조각화, 브리지 conntrack 조각화, nfnetlink_queue, xt_CHECKSUM, xfrm 출력 등 5곳에서 체크섬 계산이 완료되기 전에 이 함수를 호출합니다. 커밋 메시지에서는 이 변경 사항을 “다층 방어” 조치라고 칭하며, “입력 시점에서 더 완벽한 유효성 검증이 곧 적용될 예정”이라고 밝혔습니다. 따라서 두 번째 업스트림 수정 사항과 함께, 재부팅 없이 적용 가능한 두 번째 패치도 나올 것으로 예상됩니다. 첫 번째 패치가 적용되었다고 해서 티켓을 닫지 마십시오.

PwnEscape가 중요한 이유

게스트 경계는 하이퍼바이저보다 훨씬 더 광범위한 영역을 포괄합니다. 게스트가 자신의 패킷에 대해 말하는 내용을 신뢰하는 모든 호스트 코드는 이 경계 위에 위치합니다. 오프로드 메타데이터는 처리 속도를 높이기 위해 존재하며, 지난 18년 동안 커널은 체크섬이 어디에 배치되어야 하는지에 대해 게스트의 말을 그대로 받아들여 왔습니다.

다른 사람의 가상 머신을 실행 중이라면, 신뢰할 수 없는 게스트에서 체크섬 오프로드 기능을 즉시 비활성화하십시오. 다른 사용자에게 셸을 제공하는 경우, 비특권 사용자 네임스페이스를 비활성화하십시오. 어느 쪽이든, 사용 중인 커널 버전에 대한 수정 패치가 출시되는 즉시 실행 중인 커널에 적용하십시오. 이후에도 업스트림을 계속 주시하십시오. 더 많은 입력 검증 기능이 곧 도입될 예정입니다. 하이퍼바이저 재부팅 시 게스트를 먼저 종료해야 하는 경우, KernelCare의 재부팅 불필요 패치는 해당 커널 버전에 배포되는 즉시 실행 중인 커널의 버그를 해결해 주며, 게스트 종료나 유지보수 시간 없이도 적용할 수 있습니다.

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

연표

참조

이 게시물의 주요 출처는 2026년 10월 15일 커널 CNA에서 공개한 CVE-2026-99999 기록, Vercel의 ‘$1M Vercel Sandbox 챌린지’ 결과 보고서 (2026년 10월 14일), 연구원의 보고서 ‘PwnEscape: Guest-to-Host KVM Escape (2026년 10월 15일), 연구자가 netdev에 제출한 패치 보고서, 업스트림 수정 사항 6785011f8b16, 7개의 안정판 릴리스에 대한 LWN 공지, 그리고 데비안 보안 트래커 항목입니다.