CVE-2026-99999(PwnEscape) 분석: KVM의 취약점이 아닌 Linux 네트워크 스택의 취약점

본고에서의 '확인' 범위

본고는 공개 자료 대조를 기반으로 한 리스크 검토이며, 필자에 의한 공격 재현 시험이나 각 사업자의 비공개 구성을 감사하는 것은 아닙니다. 연구자의 실험 결과, 사업자의 공표, 필자의 분석을 구분하여 작성합니다. ※는 본고에서 확인하지 못한 사항을 의미하며, '미수정', '비해당', '그 사실이 존재하지 않음' 중 어느 것도 의미하지 않습니다.

• 결함의 소재지는
  KVM 자체가 아니라 Linux 커널의 네트워크 스택입니다. 게스트로부터 전달된 부적절한 체크섬 오프로드(checksum offload) 메타데이터가 호스트 측에서 검증된 IPv4 헤더를 나중에 덮어씁니다. VM을 사용하지 않는 TUN/AF_PACKET 경로도 검토 대상이며, 'Linux 게스트 자체와 관계없다'는 의미는 아닙니다 [3][15]. - 공개 보고에는
  호스트 메모리 누수(memory leak), 호스트의 가용성 장애, 호스트 측 관리자 권한에서의 코드 실행이라는
  실증 범위가 다른 3가지 영향이 있습니다. Vercel 실전 Sandbox에서 실증된 것은 호스트 메모리 누수였고, 충돌과 코드 실행은 연구자가 소유한 환경에서의 보고입니다. 누수가 확인되었다는 것만으로 모든 환경에서 root 획득까지 성립한다고 할 수는 없습니다 [13][15]. -
  CVE-2026-99999는 정식 공개되었으며, CNA의 CVSS v3.1 기본값은 9.3/Critical입니다. mainline 및 주요 stable 계열에 수정이 포함되어 있습니다. AWS 관리 서비스 관련 영향 없음 통보와 사쿠라(さくら)의 조사・예방적 대응은 제5절에서 범위를 나누어 정리합니다. 운영상으로는 '영향을 줄 수 있는 Linux가 어느 계층에 있는지', '누가 관리하는지', '수정된 커널로 실제로 가동하고 있는지'를 확인해야 합니다 [2][10][16].

CVE-2026-99999는 정식으로 번호가 부여되고 공개되었습니다. Linux CNA의 레코드 공개 일시는 2026년 10월 15일 12:19 UTC(21:19 JST)이며, 상태는 PUBLISHED입니다.

대상 수정은 6785011f8b16입니다. CNA에 의한 CVSS v3.1 기본값은 9.3(Critical)이며, 벡터는 CNA가 설명하는 게스트→호스트 경로에서는 AV:L이 게스트/가상 장치 경유를 의미하며, 일반적인 인터넷 수신 패킷만으로는 공격할 수 없습니다. PR:N은 이 경로에서 호스트 측 자격 증명・capability・AV:L/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H

입니다. /dev/net/tun에 대한 직접적인 접근이 필요하지 않다는 평가로, 게스트가 부적절한 메타데이터를 보낼 수 있다는 입력 조건은 필요합니다. VM을 거치지 않는 TUN/AF_PACKET 시나리오의 권한 조건까지 면제되는 것은 아닙니다[1][2][30]. -
수정 커밋: torvalds/linux6785011f8b16

'ipv4: validate checksum_start before completing checksum'(저자 Michael S. Tsirkin, 서명은 Red Hat의 메일 주소/커미터 Jakub Kicinski, Cc: stable). 커밋 메시지의 요지는 부적절한 체크섬 메타데이터가 IPv4 스택에 들어가면 skb_checksum_help가 네트워크 헤더를 손상시킬 수 있다는 점, Paulos가 발견・보고하여 타인도 독립적으로 재현했다는 점, 진입 측의 포괄적인 검증을 향후 과제로 삼으면서 우선 완성 처리 직전에 방어적 체크를 넣었다는 것입니다 [3]. -
Fixes 태그 대상: f43798c

(tun: Allow GSO using virtio_net_hdr, 2008년 7월)와 bfd5f4a

（packet: Add GSO/csum offload 지원, 2010년 2월）。CNA는 영향을 받은 시작 버전을 2.6.27로 명시하고 있습니다. AWS의 공지에는 '4.4~6.18까지 수정되지 않은 커널'이라는 다른 범위 표기가 있지만, 이를 Linux 전체의 영향 버전 및 비영향 버전 목록으로 취급해서는 안 됩니다. 해당 코드가 존재한다는 것과 실제로 공격이 도달할 수 있는 것은 별개의 문제이며, 수정 여부, 부적절한 메타데이터 입력 가능성, 그리고 해당 처리에 도달 가능한지에 따라 결정됩니다 [4][2][10]. - 6개 파일 변경 및 5개 보호 지점: ① include/net/ip.h에 공통 가드인 ip_check_csum_start() 추가, ② net/ipv4/ip_output.c의 ip_do_fragment, ③ net/bridge/netfilter/nf_conntrack_bridge.c의 nf_br_ip_fragment, ④ net/netfilter/nfnetlink_queue.c의 nf_queue_checksum_help, ⑤ net/netfilter/xt_CHECKSUM.c의 checksum_tg (CHECKSUM 타겟), ⑥ net/xfrm/xfrm_output.c의 xfrm_output. 총 44행 추가 및 12행 삭제 [3].

/* include/net/ip.h에 추가된 공통 가드 */
static inline int ip_check_csum_start(const struct sk_buff *skb)
{
...

• Vercel은 'Linux 커널의 제로데이 취약점 1건'을 가장 중요한 발견으로 다루었으며, Paulos Yibelo (pwn.ai)가 특별한 접근 권한이 부여되지 않은 표준 Sandbox에서 네트워크 스택의 결함을 발견했고, 충돌과 코드 실행은 연구자 본인의 KVM/Firecracker 환경에서 실증되었으며, 주요 클라우드 대부분이 동일한 계층에서 고객 워크로드를 분리하고 있기 때문에 공유 인프라의 위험임을 언급했습니다. 모집 당시의 위협 모델은 컨테이너 내부 root 및 microVM 내부 커널 접근까지 예상했던 것이지, '게스트 OS 내에서도 비특권적이었다'는 의미가 아닙니다 [13][14]. - 초기 보도에는 '메모리 누수와 호스트 충돌이라는 2건의 독립적인 결함'으로 설명된 부분이 있었으나, 10월 14일 Vercel 공식 발표에서는 하나의 네트워크 결함으로부터 메모리 누수, 충돌, 코드 실행을 설명하고 있습니다 [32][13].
• Vercel의 수치: 접수 보고서 1,285건, 유효 보고서 57건, 지급된 보상 총액 242,000달러, Critical 1건. 연구자 개인에게 지급되는 보상액은 보도에서 50,000달러(챌린지당 1보고 건에 대한 상한과 동일)로 언급되지만, 실제 지급액을 보여주는 일차 자료는 확인되지 않았습니다 (※) [13][14][32]。

용어 사용 시 주의사항

'KVM escape'라는 명칭은 연구자가 실증한 게스트/호스트 경계를 넘었다는 의미일 뿐, 취약점의 위치가 KVM 자체에 있는 것은 아닙니다 (기사 자체가 Figure 1에서 명시하고 있으며, 수정 대상도 IPv4, netfilter, xfrm입니다). 초기 보도에는 KVM 자체의 결함인지 아닌지에 대한 혼란이 남아 있으므로, 기사 제목에 끌려가지 않도록 주의해야 합니다 [3][15]。

• CHECKSUM_PARTIAL은 skb에 '나중에 csum_start + csum_offset 위치에 체크섬을 작성한다'는 약속을 부여합니다. 게스트는 virtio-net header로 이 값을 지정할 수 있습니다. 이는 IPv4 헤더 체크섬의 오프로드 그 자체가 아니라, 부적절한 위치 지정을 통해 네트워크 헤더가 덮어쓰여지는 점이 문제입니다 [26][15]。 - 연구자가 지적한 진입점 (__virtio_net_hdr_to_skb)의 기존 최소 길이 검증은 skb->data 상대 조건만으로는 L2 헤더 제거 후의 '네트워크 헤더 상대' 위치 관계를 보장하지 못했습니다 (좌표계의 어긋남) [15][3]。 - 호스트 측 출력 프래그먼트 처리 함수인 ip_do_fragment()에서는, 기존에 '체크섬 완성 → IP 헤더 획득/ihl 읽기' 순서였기 때문에 지연 쓰기가 IPv4 헤더 시작 부분(예: 0x45 → 0x4f)을

、IHL 5→15語）を書き換え、すでに20バイトとして検証・ルーティング済みのヘッダを60バイトとして再解釈させます [15][3]。 - 研究者の試験ケースでは、論理的な線形データ28バイトに対して60バイトのヘッダコピーが起きるため、差分の32バイトがホストメモリとして「IPオプション」に乗って外に出ます（アロケータの物理境界ではなく、skbの論理境界に対するOOB read）。32バイトはこのケースの値であり、固定量・上限ではありません [15][3]。

아래는 연구자가 설명한 IPv4 조각 경로의 도식화된 그림으로, 모든 구성에 공통되는 처리 순서를 나타내는 것은 아닙니다 [15][3]。

요컨대, '같은 패킷을 커널의 여러 부분이 서로 다른 상태로 신뢰했다'라는 TOCTOU(Time-of-Check to Time-of-Use) 유형의 문제입니다. 스레드 경쟁이 아니라, 검증과 후속 이용 사이에 지연 쓰기가 들어가는 결정론적인 처리 순서의 문제로 설명됩니다. 연구자는 이 패턴을 'deferred-metadata trust inversion'이라고 부르는 한편, 구성 요소에는 이미 알려진 기술이 포함되어 있다고 언급합니다. 이 명칭과 신규성 평가는 연구자의 주장이며, 확립된 분류명이나 다른 프로토콜/제품의 취약성을 보여주는 증거로 간주해서는 안 됩니다 [15][2]。

• 필요한 것은,
  부정확한 오프로드 메타데이터가 포함된 프레임을 수용하는 진입점(virtio-net→TAP, 또는 TUN/PACKET_VNET_HDR
  (付きAF_PACKET))과, 수정되지 않은 Linux 측에서 해당 완료 처리에 도달하는 경로 두 가지입니다. 게스트 root는 전형적인 조건이지만 보편적인 충분조건은 아니며, 하이퍼바이저의 버그는 필요하지 않습니다 [2][3]。 - 공개 수정으로 보호되는 도착지는 5곳(ip_do_fragment, 브리지 conntrack의 조각, NFQUEUE, CHECKSUM 대상, xfrm 출력)입니다. 전형적으로 호스트가 게스트 트래픽을 라우팅/NAT하여 IP 조각화하는 구성이 검토 대상이 되지만, 제품의 'default NAT'와 같은 명칭만으로 성공 여부가 결정되지는 않습니다. 반대로 브리지 conntrack을 통과하는 구성도 있기 때문에, 'L2 브리지라서 안전하다'는 이름에 의한 판단도 할 수 없습니다. 이들은 공개 수정의 보호 대상이며, 관련 모든 변종을 포괄한 필요조건 목록은 아닙니다 [3][15]。 - VM 없이도 성립할 수 있습니다. 연구자의 초기 패치 설명은 VM 게스트를 필요로 하지 않고 virtio-net header를 다루는 TUN 장치만으로 충분하다고 명시하고 있으며, AF_PACKET 측의 검증 수정도 포함되어 있습니다. 컨테이너/user namespace로부터의 도달성은 TUN 생성과 관련된 CAP_NET_ADMIN, AF_PACKET 소켓 생성을 위해 필요한 CAP_NET_RAW (해당 network namespace를 관리하는 user namespace 내부), 전달된 파일 디스크립터, 후속 경로의 각 조건에 따라 결정됩니다. 표준적인 컨테이너 설정에서의 완전한 공격 성립은 미확인입니다(※) [15][7][27][28]。

평가 대상: Linux 커널을 호스트로 하고, virtio-net/TAP 등을 통해 게스트의 메타데이터를 수신하는 가상화/샌드박스 기반(KVM/QEMU, Firecracker, Proxmox, OpenStack, oVirt, Linux에서 구동되는 crosvm 등의 VMM, AI 에이전트용 샌드박스). Linux 호스트라는 것이 해당성의 충분조건은 아닙니다. 수정 상황, 가상 NIC, 메타데이터 수신, Linux skb 경로, 후속 처리를 확인해야 하며, 제품 이름만으로 영향을 확정할 수 없습니다. vhost-user/DPDK/SR-IOV 등을 사용하는 경우에도, 기술명 자체뿐 아니라 대상 트래픽이 문제의 Linux skb 처리를 거치는지, 중간에 TAP 등으로 되돌아가는지를 조사합니다. VM을 거치지 않고 TUN/AF_PACKET 입력을 다루는 Linux도 별도의 평가 대상입니다 [2][25][19]. - Linux가 아닌 기반과 그 위의 Linux를 구분하기: VMware ESXi의 VMkernel이나 Windows Hyper-V 자체는 이번 Linux 코드의 직접적인 수정 대상이 아닙니다. Azure의 기반 역시 Microsoft는 Windows Hyper-V 기반이라고 설명합니다. 단지 Linux VM을 구동하고 있다는 이유만으로, 그 수용처인 ESXi나 Hyper-V의 물리 호스트가 본 건으로 취약해지는 것은 아닙니다. 다만, 게스트 내 Linux에서 TUN/AF_PACKET 등으로부터 해당 처리에 도달할 수 있는 경우나, 그 Linux가 다시 KVM 등의 호스트가 되는 경우에는, 그 Linux 자체의 영향을 별도로 평가합니다. 어느 Linux가 침해되는지, 그리고 어떤 경계를 넘는지에 따라 판단을 분리합니다 [3][2][22][27][28]. - gVisor/Kata Containers: gVisor는 독자적인 사용자 공간 네트워크 스택을 가지고 있지만 호스트 연결 방식으로 경계가 다르며, Kata는 VM을 사용하기 때문에 선택된 VMM·호스트 커널·백엔드의 평가가 필요합니다. '컨테이너라서 대상 제외', 'VM 형태라서 전부 대상' 둘 다 적절하지 않습니다 (구성별 영향 판정은 미확인※) [23][24]. - IPv6: 채택된 수정과 IHL(Internet Header Length) 재작성을 통한 누출의 실증은 IPv4가 대상입니다. 원문 기사는 진입점 검증 논의에는 IPv6나 중첩 헤더 등도 관련된다고 설명하지만, 본고에서는 IPv6으로 동등한 누출/root 획득이 실증된 것은 확인하지 못했습니다 (※). 이는 'IPv6에 관련된 문제가 없다'는 확인이 아니며, IPv6로 전환하는 것만으로 안전하다는 결론도 내릴 수 없습니다 [3][15].

자사 조직의 Linux가 평가 대상인지 판정하는 흐름을 도식화하면 다음과 같습니다.

이 절은 이전 절까지의 공개 자료를 공공 부문의 운영에 적용한 필자의 분석입니다. 원전이 지자체나 가버먼트 클라우드의 개별 구성에서 공격 성립을 확인했다는 의미가 아닙니다.

가바먼트 클라우드 이용자: CSP 관리의 물리 호스트를 이용자가 업데이트할 수는 없습니다. 다만 '손쓸 방법이 없다'는 것은 아니며, 대상 서비스/경로 확인, CSP에 질의(AWS는 관리 서비스 영향 없음 공표 완료, 사쿠라라는 조사 중, Google Cloud/OCI는 ※), 위탁사가 구축한 자체 관리 Linux 호스트(bare-metal 위의 KVM 등)의 업데이트 확인, 의심 워크로드 정지 등은 관리 범위에 따라 가능합니다. 누가 그 Linux를 관리하고 있는지 먼저 특정해야 합니다 [10][17]. -
'클라우드이므로 물리 분리 상당'이라는 함의: 본 건은 특정 공유 Linux 호스트 구성에서 게스트→호스트의 격리 경계가 파괴된 보고서로 설명 자료에 사용할 수 있습니다. 다만, 다른 테넌트 고객 데이터까지 획득되었다는 의미도 아니며, 모든 클라우드의 분리 메커니즘이 같은 결함으로 깨진 것이거나, 가바먼트 클라우드에서 동일한 실증이 이루어졌다는 사실로도 볼 수 없습니다. 분리 방식의 일반론과 본 건에 의한 개별 서비스 영향 확인을 나누어 작성합니다 [13][15]. -
지자체/벤더의 온프레 KVM 기반: 가령 3중 분리의 각 계층을 Proxmox/libvirt 등으로 가상화했거나, Linux KVM 기반의 어플라이언스를 이용하고 있다면, 그 명칭만으로 취약성을 확정하지 않고, Linux의 수정 상황과 입력/도달 경로를 확인합니다. 영향을 받는 구성에는 디스트리/벤더가 수정한 빌드를 적용합니다. 신뢰 수준이 다른 VM(인터넷 연결 계통과 LGWAN 계통, 외부 위탁사 VM과 청 내부 VM 등)이 영향을 받는 동일 Linux 호스트를 공유하는 경우, 경계 횡단 리스크를 우선하여 검토합니다. 원전은 지자체의 3중 분리 구성을 조사/실증하지 않았기 때문에, 이는 필자의 추정입니다 [3][2]. -
AI 에이전트 실행 기반: 외부 통신을 차단하고 있더라도, 그 전단의 TAP/호스트 처리에 공격 입력이 도달한다면 리스크는 남아 있습니다. 한편, 가상 NIC가 없고 대체 TUN/AF_PACKET 입력도 없는 구성까지 이 실증 경로로 위험하다고 할 수는 없습니다. '네트워크 차단'이 어느 계층에서 구현되었는지 명시하여 평가해야 합니다. 다른 네트워크 분리 회피 사례를 본 건의 성립 조건을 충족하는 증거로 대신할 수 없습니다 [2][15].

영향을 받는 Linux에, 수정이 포함된 지원 대상 커널/벤더 빌드를 적용한다. 호스트 측의 취약성은 게스트의 커널만 업데이트한다고 해서 수정되지 않습니다. 반면, 게스트 내부 Linux 자체에 입력 경로가 있는 경우에는 그 Linux의 업데이트도 별도로 판단합니다. 개별 커밋만을 검증 없이 가져오는 것이 아니라, 디스트리/벤더가 검증한 업데이트를 우선하고, 필요한 재부팅과 동작 확인을 진행해야 합니다. CVE 확정 대기나 후속 입력 검증 안 이유로 배포된 수정 적용을 지연시키지 않습니다 [3][10]. -
'설치됨'과 '실행 중'을 구분한다. 벤더의 수정 빌드(Amazon Linux처럼 upstream보다 작은 베이스 버전 수가 있을 수 있음)와 현재 가동 중인 커널/라이브 패치 상태를 대조합니다 [10][2]. -
후속 진입점 검증 강화를 감시한다. 채택/배포된 수정 내용에 따라 추가 업데이트를 판단합니다(반드시 추가 업데이트가 필요하다고 현시점에서 단정하지는 않습니다) [3][8]. -
당면한 노출 저감은, 구성별 보조책으로 검토한다. 아래 내용은 공개된 처리 경로로부터의 기술적 검토이며, 벤더가 보증한 공통의 회피책이 아닙니다. AWS도 본 건의 회피책을 제시하고 있지 않습니다. - 게스트 유래 트래픽이 NFQUEUE/xfrm/CHECKSUM 타겟의 해당 완료 처리를 거치지 않도록 할 수 있다면, 그 경로의 노출은 줄일 수 있습니다. 다만, 모듈의 유무만으로는 판단할 수 없으며, 다른 완료 처리가 남아있지 않은지 확인해야 합니다 [3].

• 호스트에서의 IPv4 프래그먼트 처리를 실제로 피할 수 있는 경로는, 그 처리로의 노출 저감입니다. 다만 MTU/MSS 조정만으로 악의적인 게스트가 보내는 모든 패킷에 대해 도달을 막을 수는 없으며, 다른 완료 경로에 대한 대책이 되지는 않습니다 [3][15].
• 체크섬 오프로드는 무효화하는 것이 게스트 측 설정, virtio 기능 협상, TAP 측 설정, 물리 NIC 측 설정에서 의미가 다릅니다. TUN 구현 주석에는 게스트의 협상된 기능을 파악하고 있지 않다는 내용이 있어, 출력 장치가 처리하지 않는 체크섬은 소프트웨어 처리가 될 수 있습니다.
  물리 NIC 등의 스위치를 끄는 것과, 부정확한 입력 메타데이터를 거부하는 것은 동의어가 아닙니다. VMM/백엔드/커널의 버전과 구현을 확인하지 않고 '오프로드를 무효화하면 안전하다'라고 결론 내릴 수 없습니다 [26][29].

구성 변경에 따른 통신 단절 및 성능 저하 등도 평가하며, 수정 적용의 대안으로 취급하지 않습니다 [10]。

다중 테넌트 기반에서는 가용성(Availability)에 미치는 영향도 우선적으로 평가합니다. 공격 입력 처리를 하는 Linux 호스트가 중단되면, 그 위의 VM 그룹 전체가 중단되거나 사용 불능 상태에 빠질 수 있습니다. 중요 업무에 미치는 영향, 서로 다른 신뢰 수준의 워크로드가 공존하는 상황, 업데이트 시 대피 및 복구 절차를 확인합니다. 다만, DoS(서비스 거부) 공격이 반드시 정보 유출이나 코드 실행보다 선행한다는 예측은 아니므로, 기밀성(Confidentiality)과 무결성(Integrity)의 평가를 생략할 이유가 되지 않습니다 [13][2]. -
기사화 및 자료화 시: 취약점의 위치는 'Linux 커널 네트워크 스택'으로, 실증된 경로 중 하나는 '게스트→호스트 경계 침해'로 나누어 작성합니다. CVSS의 AV:L・PR:N은 CNA가 설명하는 microVM 경로의 전제와 함께 제시합니다. 연구자 소유 환경에서의 실증을 모든 제품이나 벤더의 실제 운영 환경에서 공격 성공으로 확장하지 않습니다 [2][15]。

날짜는 원 자료 표기를 기본으로 합니다. 시차가 중요한 항목에는 UTC/PDT/JST를 병기했습니다. 비공개 연락에 대해서는 연구자의 공개 이력으로 간주하며, 당시의 이메일 원본을 개별적으로 확인한 것은 아닙니다.