สรุปสั้น
นักวิจัยด้านความมั่นคงปลอดภัยได้เปิดเผยช่องโหว่ประเภท use-after-free (การใช้หน่วยความจำหลังจากถูกคืนไปแล้ว) ใน KVM hypervisor ของ Linux ซึ่ง VM แขก (guest virtual machine — เครื่องเสมือนที่รันอยู่บนเครื่องแม่) สามารถกระตุ้นช่องโหว่นี้เพื่อทำให้สถานะ shadow-page ของเคอร์เนลบนเครื่องแม่ (host) เสียหายได้ ช่องโหว่นี้ถูกตั้งชื่อว่า Januscape และมีรหัส CVE-2026-53359 จุดบกพร่องอยู่ในโค้ด shadow MMU ที่ KVM ใช้ร่วมกันทั้งบนชิป Intel และ AMD โดยตัวโจมตีสาธิตสาธารณะ (proof-of-concept) จะทำให้ host แครชทั้งเครื่อง ส่วนนักวิจัยอ้างว่ามี exploit อีกตัวที่ยังไม่ปล่อยออกมาซึ่งเปลี่ยนช่องโหว่เดียวกันนี้ให้กลายเป็นการรันโค้ดบน host ได้เต็มรูปแบบ
นาย Hyunwoo Kim (@v4bel) นักวิจัยด้านความมั่นคงปลอดภัยเป็นผู้ค้นพบและรายงานช่องโหว่นี้ เขาอธิบายว่า Januscape คือ exploit แบบ guest-to-host ตัวแรกที่กระตุ้นได้ทั้งบน Intel และ AMD เท่าที่มีการเปิดเผยต่อสาธารณะ และช่องโหว่นี้ซ่อนตัวอยู่โดยไม่มีใครสังเกตเห็นมานานราว 16 ปี ตามที่ Kim ระบุ exploit ตัวนี้ถูกใช้เป็นการส่งผลงานช่องโหว่ zero-day ในโครงการ kvmCTF ของ Google ซึ่งเป็นโปรแกรมให้รางวัลช่องโหว่ KVM แบบควบคุมที่จ่ายสูงสุดถึง 250,000 ดอลลาร์สหรัฐสำหรับการหนีจาก guest สู่ host แบบเต็มรูปแบบ การโจมตีต้องอาศัยเงื่อนไขสองอย่างจากฝั่ง guest คือสิทธิ์ root ภายใน VM ซึ่งเป็นเรื่องปกติบนอินสแตนซ์คลาวด์ที่เช่ามา และการเปิด nested virtualization ไว้ที่ host
รายละเอียดข่าว
เว็บไซต์ The Hacker News (THN) รายงานเมื่อวันที่ 6 กรกฎาคม พ.ศ. 2569 ว่า มีการเปิดเผยช่องโหว่ Januscape (CVE-2026-53359) ในส่วน shadow MMU ของ KVM hypervisor บน Linux เพื่อให้ VM รันได้ KVM จะเก็บชุดตารางหน้าหน่วยความจำ (page tables) ส่วนตัวของตัวเองไว้ชุดหนึ่งเพื่อจำลองผังหน่วยความจำของ guest เมื่อ KVM ต้องการหน้าติดตาม (tracking page) มันจะมองหาหน้าเดิมที่มีอยู่แล้วเพื่อนำกลับมาใช้ซ้ำ
ปัญหาคือ KVM จับคู่หน้าเหล่านี้ด้วยที่อยู่หน่วยความจำ (memory address) เพียงอย่างเดียว โดยไม่สนใจว่าหน้าติดตามที่หยิบมานั้นเป็นชนิดใด ทั้งที่หน้าสองชนิดที่ต่างกันสามารถมีที่อยู่เดียวกันได้แต่ทำหน้าที่คนละอย่างโดยสิ้นเชิง ทำให้ KVM บางครั้งนำหน้าผิดชนิดกลับมาใช้ ความสับสนนี้ทำให้บันทึกภายในของ KVM ที่ระบุว่าหน้าใดเป็นของส่วนไหนปั่นป่วน และเมื่อบันทึกเหล่านั้นผิดพลาด ก็ต้องมีบางอย่างพังตามมา ส่วนใหญ่แล้วเคอร์เนลจะสังเกตเห็นความผิดปกติและปิดตัวเองลงทันทีเพื่อเลี่ยงความเสียหาย ซึ่งนั่นคือสิ่งที่การสาธิตสาธารณะกระตุ้นให้เกิดขึ้น นั่นคือ guest หนึ่งตัวสามารถล้ม host ทั้งเครื่อง พา VM ตัวอื่นทุกตัวบนเครื่องเดียวกันล้มตามไปด้วย
กรณีที่หายากกว่าแต่ร้ายแรงกว่าคือ เมื่อหน้าติดตามที่ถูกคืนไปแล้วถูกแจกจ่ายไปใช้งานอื่นก่อนที่เคอร์เนลจะเก็บกวาดเสร็จ ขั้นตอนเก็บกวาดจะเขียนค่าลงในหน่วยความจำที่มันไม่ได้เป็นเจ้าของอีกต่อไป ผู้โจมตีควบคุมได้เพียงว่าการเขียนนั้นจะไปตกที่ไหน ไม่ใช่ว่าจะเขียนค่าอะไรลงไป แต่แม้จะมีจุดยึดจำกัดเพียงเท่านี้ก็สามารถต่อยอดจนรันโค้ดบน host ได้ ช่องโหว่นี้ทำงานเหมือนกันทั้งบนชิป Intel และ AMD ต่างกันเพียงขั้นตอนสุดท้ายที่ยากที่สุดในการเปลี่ยนเป็นการควบคุมเต็มรูปแบบเท่านั้นที่ต้องใช้วิธีต่างกันในแต่ละค่าย
รายละเอียดช่องโหว่
โค้ดที่มีช่องโหว่ปรากฏอยู่ตั้งแต่ commit 2032a93d66fa เมื่อเดือนสิงหาคม 2010 (ยุคเคอร์เนล 2.6.36) และได้รับการแก้ไขด้วย commit 81ccda30b4e8 ที่รวมเข้าสู่ mainline เมื่อวันที่ 19 มิถุนายน 2026 การโจมตีต้องการสองสิ่งจากฝั่ง guest คือสิทธิ์ root ภายใน VM ซึ่งเป็นเงื่อนไขที่พบได้ทั่วไปบนอินสแตนซ์คลาวด์ที่เช่ามา และ nested virtualization (การรันเครื่องเสมือนซ้อนในเครื่องเสมือน) ที่ host เปิดเผยไว้ แม้บน host ที่ใช้ฮาร์ดแวร์ EPT หรือ NPT เป็นค่าเริ่มต้น การเปิด nested virtualization ก็จะบังคับให้ KVM ย้อนกลับไปใช้ shadow MMU แบบเดิมซึ่งเป็นจุดที่ช่องโหว่ฝังอยู่ โดย exploit นี้ไม่ต้องอาศัยความร่วมมือจาก QEMU หรือ userspace VMM ใด ๆ เพราะเป็นจุดบกพร่องภายในเคอร์เนล KVM ล้วน ๆ
ประเด็นที่น่ากังวลในทางปฏิบัติคือสภาพแวดล้อม x86 ใด ๆ ที่โฮสต์ guest ที่ไม่น่าเชื่อถือพร้อมเปิด nested virtualization ผู้โจมตีที่เช่าอินสแตนซ์เพียงตัวเดียวสามารถทำให้ host แครช พา VM ของผู้เช่ารายอื่นทุกตัวบนเครื่องกายภาพเดียวกันล้มตามไปด้วย นาย Kim ระบุว่า exploit ฉบับเต็มที่ยังไม่ปล่อยออกมาสามารถรันโค้ดในระดับ root บน host ได้ ซึ่งจะเปิดทางให้เข้าถึง guest ตัวอื่นบนเครื่องเดียวกันด้วยสิทธิ์ root นั้น บนดิสโทรอย่าง RHEL ที่ /dev/kvm เปิดให้เขียนได้จากทุกคน (0666) Kim ตั้งข้อสังเกตว่าช่องโหว่เดียวกันยังใช้ยกระดับสิทธิ์ในเครื่อง (local privilege escalation) เป็น root ได้ด้วย แม้เส้นทาง guest-to-host จะเป็นการใช้งานที่มีผลกระทบสูงกว่า นับเป็นการเปิดเผย exploit เคอร์เนล Linux ตัวที่สามของ Kim ในเวลาราวสองเดือน ต่อจาก Dirty Frag (พฤษภาคม 2026) และ ITScape (CVE-2026-46316 การหนี guest-to-host บน KVM/arm64 ในเดือนมิถุนายน) นอกจากนี้ยังมี CVE-2026-46113 ซึ่งเป็น use-after-free ใน shadow paging ของ KVM x86 อีกตัวที่ถูกแก้ในเดือนพฤษภาคม 2026 รวมเป็นสอง use-after-free ในโค้ด shadow MMU เดิมภายในสองเดือน
ผลกระทบต่อไทย
ผู้ให้บริการคลาวด์และองค์กรในไทยที่รันโครงสร้างพื้นฐานเวอร์ชวลไลเซชันบน Linux KVM โดยเฉพาะที่ให้บริการแบบ multi-tenant (หลายผู้เช่าใช้เครื่องกายภาพร่วมกัน) และเปิด nested virtualization ไว้ ควรถือว่าตนเองเป็นเป้าหมายลำดับต้น เพราะผู้โจมตีเพียงเช่า VM หนึ่งตัวก็สามารถล้ม host ทั้งเครื่องจนกระทบผู้เช่ารายอื่นทั้งหมด และหาก exploit ฉบับเต็มหลุดออกมา ก็อาจนำไปสู่การเข้าถึงข้อมูลข้ามผู้เช่าในระดับ root ระบบที่ใช้ทดสอบ CI/CD, sandbox วิเคราะห์มัลแวร์ และแล็บที่รัน VM ซ้อน VM มักเปิด nested virtualization ไว้ จึงเป็นจุดเสี่ยงที่ทีมไอทีไทยควรตรวจสอบเป็นพิเศษ
คำแนะนำ
ควรอัปเดตเคอร์เนลให้มี commit 81ccda30b4e8 โดยเวอร์ชัน stable ที่แก้แล้วออกมาเมื่อวันที่ 4 กรกฎาคม 2026 ได้แก่ 7.1.3, 6.18.38, 6.12.95, 6.6.144, 6.1.177, 5.15.211 และ 5.10.260 เนื่องจาก NVD ยังไม่ได้กำหนดคะแนน CVSS จึงไม่ควรรอคะแนนก่อนแล้วค่อยแพตช์ หากดำเนินการบน host x86 KVM ที่รับ guest หลายผู้เช่าพร้อม nested virtualization ให้ยืนยันว่าเคอร์เนลรวม commit ดังกล่าวแล้ว โดยการ backport ของแต่ละดิสโทรอาจใช้เลขเวอร์ชันต่างกัน จึงควรตรวจ changelog ของแพ็กเกจแทนที่จะเชื่อผลจาก uname -r เพียงอย่างเดียว
หากยังแพตช์ทันทีไม่ได้ การปิด nested virtualization (kvm_intel.nested=0 หรือ kvm_amd.nested=0) จะตัดเส้นทางการโจมตีสำหรับ guest ที่ไม่น่าเชื่อถือออกไป ทั้งนี้ host ที่เป็น ARM64 ไม่ได้รับผลกระทบจาก Januscape (ITScape/CVE-2026-46316 เป็นคนละปัญหาบน KVM/arm64) เนื่องจากตัวสาธิตสาธารณะแสดงให้เห็นการทำให้ host แครชได้อย่างน่าเชื่อถือจาก guest ที่โหลด kernel module ได้และใช้เวลาแข่งสภาวะเพียงไม่กี่วินาทีถึงไม่กี่นาที จึงควรจัดให้ host x86 KVM ที่เปิด nested virtualization เป็นเป้าหมายการแพตช์ลำดับความสำคัญสูง