นักวิจัยด้านความปลอดภัย Hyunwoo Kim (V4bel) เปิดเผยช่องโหว่ Use-After-Free ใน Shadow MMU ของ KVM/x86 ซึ่งตั้งชื่อว่า "Zapscape" (CVE-2026-64561) เปิดทางให้ Guest VM ที่มีสิทธิ์ Root สามารถหลบหนี (Escape) ออกจาก Virtual Machine และรันโค้ดบน Linux Host ด้วยสิทธิ์ Root ระดับ Kernel ปัจจุบันมี PoC เผยแพร่สู่สาธารณะแล้วบน GitHub เพิ่มความเสี่ยงที่จะถูกนำไปใช้โจมตีจริง
รายละเอียดช่องโหว่
ช่องโหว่นี้อยู่ใน Shadow MMU ของ KVM ซึ่งทำหน้าที่จัดการการแปลงที่อยู่หน่วยความจำเมื่อมีการใช้งาน Nested Virtualization (VM ที่รัน VM ซ้อนอยู่ภายใน) กลไกของช่องโหว่มีดังนี้:
- Path การตรวจสอบ Page Fault สองเส้นทางใน Shadow MMU ตรวจสอบความถูกต้องของ Shadow Root ก่อนที่จะ Reclaim หน่วยความจำ Shadow Page แทนที่จะตรวจสอบหลังจากนั้น
- เมื่อ Shadow Root ถูก Reclaim ไปแล้ว KVM ยังคงสร้าง Mapping ต่อไปโดยอ้างอิงจากโครงสร้างที่ถูก Invalidate แล้ว
- เกิด Use-After-Free ในเส้นทาง Recursive Zap ที่ทำงานเมื่อมีการ Reclaim Shadow Page ทำให้ผู้โจมตีสามารถควบคุมหน่วยความจำที่ถูกคืนไปแล้วได้
โค้ดที่มีปัญหานี้ถูกเพิ่มเข้ามาตั้งแต่ปี 2020 และได้รับการแก้ไขต้นทางแล้วผ่าน Commit 2abd5287f083 เมื่อวันที่ 21 กรกฎาคม 2569 โดยแพตช์เปลี่ยนลำดับการตรวจสอบ: KVM จะตรวจสอบว่า Root Page ถูกทำให้ไม่ถูกต้องหลังจากเตรียม MMU Page ให้พร้อมใช้งานแล้วหรือไม่ หากพบว่าถูก Reclaim ไปแล้ว ระบบจะ Retry แทนที่จะใช้โครงสร้างที่ไม่ถูกต้องต่อไป
PoC ที่เผยแพร่สู่สาธารณะสามารถรันโค้ดด้วยสิทธิ์ Root บน Host ได้จริง ไม่ใช่เพียงทำให้ระบบ Panic หรือ VM อื่นที่ใช้ Host ร่วมกันล่มเท่านั้น
ระบบที่ได้รับผลกระทบ
- Linux Host ที่ใช้ KVM/x86 และเปิดใช้งาน Nested Virtualization
- สภาพแวดล้อม Infrastructure-as-a-Service (IaaS) ที่อนุญาตให้ Guest VM มีสิทธิ์ Root ซึ่งเป็นเงื่อนไขทั่วไปในการเช่าใช้ VM แบบมาตรฐาน
- ผู้ให้บริการ Cloud/Hosting ที่รัน Workload ของลูกค้าหลายรายบน Host เดียวกันโดยใช้ KVM
ผลกระทบที่อาจเกิดขึ้น
- Guest VM ที่มีสิทธิ์ Root สามารถหลบหนีออกจาก VM และรันโค้ดบน Host ด้วยสิทธิ์ Root ระดับ Kernel
- กระทบต่อ VM อื่นทั้งหมดที่ใช้ Host ร่วมกัน ไม่ใช่แค่ VM ที่ถูกใช้เป็นจุดเริ่มโจมตี
- ผู้ให้บริการ Cloud ที่ใช้ KVM รองรับลูกค้าหลายราย (Multi-Tenant) มีความเสี่ยงเป็นพิเศษ เนื่องจากลูกค้ารายหนึ่งที่มีสิทธิ์ Root ใน VM ของตนเองอาจโจมตีข้ามไปกระทบลูกค้ารายอื่นได้
สิ่งที่องค์กรควรทำ
- ▸ ตรวจสอบว่า Linux Kernel ของ Host ที่ใช้ KVM ได้รวม Commit
2abd5287f083(หรือแพตช์ที่เกี่ยวข้อง) แล้วหรือไม่ อัปเดตทันทีหากยังไม่ได้แพตช์ - ▸ องค์กรที่ให้บริการ IaaS หรือรัน Multi-Tenant KVM ควรจัดลำดับความสำคัญการอัปเดตนี้เป็นพิเศษ เนื่องจากมี PoC สาธารณะแล้ว
- ▸ ตรวจสอบว่าจำเป็นต้องเปิดใช้งาน Nested Virtualization จริงหรือไม่ หากไม่จำเป็นให้ปิดใช้งานเพื่อลดพื้นผิวการโจมตี
- ▸ ติดตาม Log และพฤติกรรมผิดปกติของ VM ที่อาจบ่งชี้ความพยายามโจมตีระหว่างรอการอัปเดต
แนวทางลดความเสี่ยงระยะยาว
1. จัดกระบวนการ Patch Kernel ของ Hypervisor Host ให้รวดเร็วเป็นพิเศษเมื่อมี PoC สาธารณะ
ช่องโหว่ระดับ VM Escape ที่มี PoC เผยแพร่แล้วมีความเสี่ยงสูงกว่าช่องโหว่ทั่วไปอย่างมีนัยสำคัญ
2. จำกัดการเปิดใช้งาน Nested Virtualization เฉพาะ Workload ที่จำเป็นจริงเท่านั้น
ลดพื้นผิวการโจมตีของช่องโหว่ในกลุ่ม Shadow MMU ซึ่งเกี่ยวข้องโดยตรงกับฟีเจอร์นี้
3. พิจารณาแยก Workload ที่มีความเสี่ยงสูงหรือไม่น่าเชื่อถือออกจาก Host ที่ใช้ร่วมกับ Workload สำคัญ
ลดผลกระทบหากเกิดการโจมตีสำเร็จในสภาพแวดล้อม Multi-Tenant
4. ติดตาม Security Advisory ของ Linux Kernel และ KVM อย่างสม่ำเสมอ
โดยเฉพาะองค์กรที่ให้บริการ Cloud/Hosting ซึ่งช่องโหว่ระดับ Hypervisor มีผลกระทบเป็นวงกว้างกว่าปกติ
วิเคราะห์ในมุมมองจาก TXEC
Zapscape เป็นตัวอย่างที่ชัดเจนของความเสี่ยงเชิงโครงสร้างในสภาพแวดล้อม Multi-Tenant Cloud ที่พึ่งพา Hypervisor เป็นกลไกแยก (Isolate) Workload ของลูกค้าแต่ละราย เมื่อช่องโหว่ระดับ Shadow MMU เปิดทางให้ VM หลบหนีสู่ Host ได้จริงและมี PoC สาธารณะรองรับ ความเสี่ยงจึงไม่ได้จำกัดอยู่แค่ VM ที่ถูกโจมตี แต่ลุกลามไปถึงลูกค้ารายอื่นที่ใช้ Host เดียวกัน
TXEC มองว่าองค์กรที่ให้บริการหรือใช้งาน IaaS ควรตรวจสอบสถานะการแพตช์ของผู้ให้บริการ Cloud ที่ใช้งานอยู่ และสำหรับองค์กรที่บริหาร KVM Infrastructure เอง ควรจัดลำดับความสำคัญการอัปเดตนี้ให้เร็วกว่าปกติ เนื่องจากช่องโหว่ประเภท VM Escape เป็นหนึ่งในความเสี่ยงที่ร้ายแรงที่สุดสำหรับสภาพแวดล้อม Virtualization แบบ Multi-Tenant
รู้ก่อน ตรวจพบเร็ว ลดความเสียหายได้มากกว่า
[ แหล่งอ้างอิง: The Hacker News, CyberSecurityNews, TuxCare, CloudLinux ]