โมเดลตึกห้องเช่าอะคริลิกใสแต่ละห้องมีเซิร์ฟเวอร์ ใช้ท่อทองแดงร่วมกัน และมีของเหลวสีอำพันรั่วจากข้อต่อขึ้นไปห้องเจ้าของตึก
newssecuritylinuxkernelcloudvirtualizationcve

PwnEscape: ช่องโหว่ Linux Kernel ที่ทำให้ VM แขกอ่านหน่วยความจำโฮสต์ได้

น้องกายEngineering

เมื่อวานนี้ (15 ตุลาคม 2026) วงการความปลอดภัยไซเบอร์ทั้งโลกเพิ่งรู้เรื่องช่องโหว่ตัวร้ายใน Linux Kernel ที่ชื่อ CVE-2026-99999 หรือที่นักวิจัยเรียกติดปากว่า PwnEscape ช่องโหว่นี้มีคะแนน CVSS สูงถึง 9.3 (Critical) ตามที่ kernel CNA ให้คะแนนไว้ (The Hacker News) โดยโค้ดที่รันอยู่ในเครื่องเสมือน (guest VM) สามารถอ่านหน่วยความจำของเครื่องโฮสต์ (host) ได้ รีบูตเครื่องโฮสต์ให้ดับสนิท และในห้องทดลองยังสามารถรันโค้ดควบคุมเครื่องโฮสต์ได้ด้วย (pwn.ai) (Vercel Blog)

ช่องโหว่นี้ถูกค้นพบโดย Paulos Yibelo จาก pwn.ai ภายในสามวันหลัง Vercel เปิดการแข่งขัน Sandbox Challenge มูลค่า 1 ล้านดอลลาร์เมื่อวันที่ 18 สิงหาคม 2026 (pwn.ai) Vercel ยืนยันว่าเป็นรายงานที่สำคัญที่สุดในโปรแกรมนี้ และจ่ายเงินรางวัลรวมทั้งโครงการ 242,000 ดอลลาร์จากรายงานทั้งหมด 1,285 ฉบับ (Vercel Blog) ปัจจุบันยังไม่มีหลักฐานว่ามีการโจมตีในโลกจริง และแพตช์แก้ไขถูกผสานเข้า mainline kernel แล้ว

สรุป 30 วินาที: เกิดอะไรขึ้น

Paulos Yibelo ค้นพบช่องโหว่ในโค้ด networking ของ Linux Kernel โดยเฉพาะส่วนที่จัดการ checksum ของแพ็กเก็ต IPv4 ช่องโหว่ทำให้ metadata ที่มาจาก guest VM สามารถเปลี่ยนแปลง header ของแพ็กเก็ตหลังจาก kernel ตรวจสอบแล้ว ส่งผลให้เกิด host memory disclosure ประมาณ 32 ไบต์ต่อแพ็กเก็ต (The Hacker News) นอกจากนี้ยังทำให้ host crash และในสภาพแวดล้อม lab ยังสามารถ escalate ไปรันโค้ดบน host ได้ด้วย (pwn.ai)

Vercel บอกว่าช่องโหว่นี้ไม่ใช่ความผิดของระบบ Sandbox ของเขา แต่เป็น bug ใน upstream Linux Kernel ที่ทุก cloud provider ใช้ร่วมกัน (Vercel Blog) แพตช์แก้ไขคือ commit 6785011f8b16 ที่เพิ่มการตรวจสอบ checksum_start ก่อนทำ checksum completion (oss-security) (Tenable)

เวอร์ชัน kernel ที่แก้ไขแล้วใน stable branch คือ 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.57 และ 7.2.11 (The Hacker News)

ทำไมเรื่องนี้เกี่ยวกับคุณ

ลองนึกภาพว่าคุณเปิดเว็บไซต์ขายของออนไลน์ ใช้บริการ cloud hosting หรือแม้แต่ใช้ Google Docs, Zoom, หรือแอปธนาคารออนไลน์ที่อยู่หลังบ้านบนเครื่อง server เดียวกันกับคนอื่นเป็นร้อยคน ช่องโหว่นี้คือ “รูรั่วในท่อประปาของตึกคอนโด” ที่ทำให้คนในห้องหนึ่งสามารถแอบดูน้ำในท่อของห้องอื่น หรือแม้แต่ทำให้ทั้งตึกดับได้ (pwn.ai)

คนทั่วไปที่ใช้บริการคลาวด์อาจไม่รู้ตัว แต่บริการที่เราใช้ทุกวันล้วนอาศัย Linux Kernel ในการแยกข้อมูลของลูกค้าหลายรายบนเครื่องเดียวกัน ถ้า attacker ที่มีสิทธิ์รันโค้ดใน VM หนึ่งสามารถทะลุไปโฮสต์ได้ ผลกระทบอาจลามไปถึงข้อมูลของคนอื่น ๆ (Vercel Blog) สำหรับนักพัฒนาและเจ้าของเว็บเล็ก ๆ ที่โฮสต์เองด้วย Proxmox, KVM หรือ cloud instance เรื่องนี้คือความเสี่ยงโดยตรงต่อ server ที่เก็บข้อมูลลูกค้าและเงินในบัญชี

ทำงานยังไง

ปัญหาอยู่ที่ระบบ “deferred checksum” หรือการคำนวณ checksum แบบผ่อนผันใน Linux networking stack ตัวแปร skb->csum_start และ skb->csum_offset บอก kernel ว่าต้องไปเขียนผล checksum ที่ตำแหน่งไหนในแพ็กเก็ต แต่ attacker ใน guest VM สามารถควบคุม metadata เหล่านี้ได้ ทำให้ kernel เขียนทับลงบน IPv4 header หลังจากที่ header ถูกตรวจสอบและนำไปใช้ตัดสินใจแล้ว (pwn.ai)

กระบวนการคือ 1) kernel ตรวจสอบแพ็กเก็ต IPv4 ปกติ 2) ต่อมาเมื่อถึงขั้นตอน fragmentation หรือส่งแพ็กเก็ตออก ฟังก์ชัน skb_checksum_help() จะถูกเรียกและเขียนข้อมูลตาม metadata ที่ถูกบิดเบือน 3) ทำให้ไบต์แรกของ header เปลี่ยนจาก 0x45 เป็น 0x4f ส่งผลให้ kernel คิดว่า header ยาวขึ้นจาก 20 เป็น 60 ไบต์ และอ่านข้อมูลจากหน่วยความจำโฮสต์มาผสมในแพ็กเก็ต (pwn.ai) (Tenable)

ลองเปรียบเทียบกับ คอนโดห้องเช่าหลายห้องที่ใช้ท่อประปาร่วมกัน ห้องผู้เช่า (guest) ส่ง “คำสั่งบิดน็อตน้ำ” ที่บอกว่าต้องเปิดน้ำตรงไหน แต่คำสั่งนั้นถูกเขียนหลังจากผู้จัดการตึก (kernel) ตรวจสอบแล้วว่าปลอดภัย ผลคือน้ำจากห้องอื่น (host memory) ไหลย้อนกลับมาที่ก๊อกห้องคุณ หรือทำให้ทั้งระบบประปาของตึกพังเลยก็ได้ นี่คือ analogy ที่ตรงกับ bug นี้เป๊ะ ๆ (pwn.ai)

แพตช์ที่ถูกยอมรับคือการตรวจสอบว่า checksum_start ต้องอยู่หลัง IPv4 header ก่อนจะทำการเขียน checksum (oss-security)

จุดหักมุม: Bug ไม่ได้อยู่ที่ Hypervisor

สิ่งที่ทำให้วงการตกใจคือ bug นี้ไม่ได้อยู่ใน KVM, Firecracker หรือ hypervisor ตัวใดตัวหนึ่ง แต่กลับอยู่ใน Linux networking stack ที่โฮสต์ทุกเครื่องใช้ (pwn.ai) Vercel ย้ำว่า Sandbox ของเขาปลอดภัยเกินมาตรฐานอุตสาหกรรมและไม่มี misconfiguration แต่ช่องโหว่นี้ยังทะลุกำแพงได้เพราะมันอยู่ในโค้ดที่ทุกคนเชื่อว่า “ปลอดภัยแล้ว” (Vercel Blog)

Paulos ใช้เครื่องมือ Omega-Pwn ที่ผสมมนุษย์กับ GPT-5.6 Sol ในการวิเคราะห์ source code เป็นเวลานานหลายวัน กว่าจะเจอ primitive ใหม่นี้ที่เรียกว่า “untrusted checksum metadata can rewrite security-sensitive packet fields after validation” (pwn.ai) (The Hacker News)

เรื่องเงิน / ผลกระทบ

Vercel จ่ายรางวัลให้ Paulos และทีมรวมแล้ว 242,000 ดอลลาร์จาก challenge ทั้งหมด โดย PwnEscape คือรายงาน Critical เพียงรายงานเดียว (Vercel Blog) สำหรับธุรกิจขนาดเล็กที่ใช้ cloud hosting อาจไม่เสียเงินโดยตรง แต่หาก provider ไม่แพตช์ทัน อาจเกิดข้อมูลรั่วไหลหรือ downtime ที่กระทบรายได้

สำหรับผู้ให้บริการโฮสติ้งในไทย ถ้าใช้ kernel เวอร์ชันเก่าและมีลูกค้าหลายรายบนเครื่องเดียวกัน ความเสี่ยงคือลูกค้าอาจอ่านข้อมูลของกันและกันได้โดยไม่ตั้งใจ หรือทำให้เครื่องโฮสต์ล่มทั้งเครื่อง (The Hacker News) ผลกระทบทางอ้อมคือความเชื่อมั่นของลูกค้าที่อาจหายไปหากข่าวรั่ว

ข้อมูลที่ยังไม่ชัด และจุดที่แหล่งข่าวพูดไม่ตรงกัน

  • เวอร์ชัน kernel ที่แก้ไขแล้วมีรายชื่อชัดเจนจาก The Hacker News แต่บาง distro อาจ backport โดยไม่เปลี่ยนเลขเวอร์ชัน ทำให้ผู้ดูแลระบบต้องตรวจสอบ advisory ของแต่ละ distro (The Hacker News)
  • oss-security โพสต์เมื่อ 15 ตุลาคม 2026 บอกว่ามีการพูดคุยใน netdev mailing list ก่อนหน้านี้ แต่ยังไม่แน่ใจว่า distros@ ถูกแจ้งหรือยัง (oss-security)
  • Tenable และ pwn.ai ยืนยันว่าเป็น defence-in-depth measure และ input validation ที่สมบูรณ์กว่าจะมาในภายหลัง (Tenable) (pwn.ai)
  • ยังไม่มีตัวเลขราคาในไทยหรือกำหนดการที่ cloud provider ในไทยจะอัพเดต kernel

แล้วเราควรทำอะไร

สำหรับคนทั่วไป (office workers, พ่อแม่, นักเรียน, เจ้าของธุรกิจเล็ก):

  1. ไม่ต้องทำอะไรกับโทรศัพท์หรือคอมพิวเตอร์ส่วนตัว เพราะช่องโหว่นี้ต้องการสิทธิ์รันโค้ดใน guest VM ก่อน
  2. ถ้าใช้บริการเว็บโฮสติ้งหรือ SaaS ให้สอบถาม provider ว่าอัพเดต kernel แล้วหรือยัง
  3. เปิดการแจ้งเตือนข่าวความปลอดภัยจาก provider ที่ใช้อยู่

สำหรับ IT คนที่ดูแล cloud / hosting / server:

  1. ตรวจสอบเวอร์ชัน kernel ของ host ด้วยคำสั่ง uname -r แล้วเปรียบเทียบกับรายชื่อ stable ที่แก้ไขแล้ว (The Hacker News)
  2. อัพเดต kernel เป็นเวอร์ชันที่รวม commit 6785011f8b16 แล้ว (เช่น 5.10.272 เป็นต้นไป) แล้วรีบูตโฮสต์
  3. ตรวจสอบ advisory จาก distro ของคุณ (Ubuntu, Debian, RHEL, Alpine ฯลฯ) เพราะบางตัวอาจใช้เลขเวอร์ชันต่างกัน
  4. พิจารณาใช้ mitigation ชั่วคราว เช่น ปิด nested virtualization และจำกัด permission ของ microVM process ตามที่ Vercel ทำ (Vercel Blog)

สำหรับทีมความปลอดภัยและ developer:

  1. ติดตาม upstream patch และ backport เพิ่มเติมที่จะมาในอนาคต
  2. ตรวจสอบระบบ sandbox หรือ container ที่ใช้ว่ามีการ trust guest input มากเกินไปหรือไม่
  3. ทดสอบระบบตัวเองด้วยแนวคิด “assume the next zero day” ตามคำแนะนำของ Trail of Bits

ผมมองว่า…

ผมมองว่าเรื่องนี้เป็นตัวอย่างคลาสสิกของการที่เราเชื่อใจ “metadata” มากเกินไป ไม่ใช่เพราะ hypervisor อ่อนแอ แต่คือเพราะ networking stack ที่ซับซ้อนเกินกว่าที่ใครจะคาดคิดหมดทุกมุม ทุก cloud provider ควรขอบคุณ Vercel และ Paulos ที่ทำให้ bug นี้ถูกเปิดเผยก่อนที่จะมีใครเอาไปใช้โจมตีจริง ๆ

ปิดท้าย: สิ่งที่ต้องจับตา

  • การที่ distro ต่าง ๆ จะนำแพตช์นี้ไปใช้เมื่อไหร่ โดยเฉพาะ provider cloud ในไทย
  • ส่วนที่สองของบทความจาก pwn.ai ที่จะพูดถึง network escape เพิ่มเติม
  • การพัฒนา input validation ที่สมบูรณ์กว่านี้ตามที่ kernel maintainer บอกว่าจะตามมา
  • ว่า cloud provider รายใหญ่จะออก advisory แบบ coordinated disclosure หรือไม่

Recap

  • ตรวจสอบ kernel version ของ host server หรือ cloud instance ที่คุณดูแล
  • อัพเดต kernel เป็นเวอร์ชันที่แก้ไข CVE-2026-99999 แล้ว (เช็ค distro advisory)
  • รีบูต host หลังอัพเดต (guest update ไม่ช่วย)
  • ถาม provider ว่าอัพเดตแล้วหรือยัง โดยเฉพาะบริการเว็บโฮสติ้งและ SaaS
  • ติดตามข่าวจาก pwn.ai และ kernel.org สำหรับรายละเอียดเพิ่มเติม
  • พิจารณา hardening เพิ่ม เช่น จำกัด permission ของ VM process
  • อย่าตกใจเกินไป ถ้ายังไม่มี in-the-wild exploitation