พบช่องโหว่ระดับ High รหัส CVE-2026-53361 (CVSS 7.1) หรือชื่อเล่นที่นักวิจัยตั้งให้ว่า "BadGarbage" ใน Linux Kernel บริเวณกลไก Garbage Collector ของ AF_UNIX Socket เป็นปัญหา Use-After-Free ร่วมกับ Race Condition ที่เปิดทางให้ผู้ใช้ภายในระบบหรือ Process ที่รันอยู่ใน Container สามารถสร้างความเสียหายต่อหน่วยความจำระดับ Kernel และยกระดับสิทธิ์เป็น Root บน Host ได้โดยไม่ต้องมีสิทธิ์พิเศษใดๆ มาก่อน ที่น่ากังวลยิ่งกว่าคือ Exploit Code ที่ใช้งานได้จริงถูกเผยแพร่สู่สาธารณะแล้วตั้งแต่วันที่ 10 สิงหาคม 2569
รายละเอียดช่องโหว่
CVE-2026-53361 เกิดจาก Race Condition ระหว่างการทำงานของ Garbage Collector (GC) ของ AF_UNIX Socket กับการเรียกใช้ MSG_PEEK บน File Descriptor ที่กำลังถูกส่งผ่าน Unix Socket โดยปกติแล้ว GC มีหน้าที่เก็บกวาด Socket ที่ไม่ถูกใช้งานแล้วเพื่อคืนหน่วยความจำ แต่กลไกป้องกันไม่ให้การ Peek แทรกแซงระหว่าง GC ทำงานกลับมีข้อบกพร่อง
โดยเฉพาะ ฟังก์ชัน unix_schedule_gc() และ wait_for_unix_gc() ตั้งค่าตัวแปร gc_in_progress เป็น True ก่อนที่จะ Queue งาน GC เท่านั้น ทำให้เกิดช่องว่างที่หากมีการ Schedule GC รอบที่สองแข่งกับรอบที่กำลังทำงานอยู่ (unix_gc()) ตัวแปร gc_in_progress อาจแสดงค่า False ในขณะที่ GC ยังทำงานอยู่จริง ฟังก์ชัน unix_peek_fpl() ซึ่งควรอาศัยค่าตัวแปรนี้เพื่อหลีกเลี่ยงการรบกวน GC จึงสามารถแทรกเข้ามาได้ในจังหวะที่ไม่ควรเกิดขึ้น
ผลลัพธ์คือการทำ MSG_PEEK พร้อมกันบน File Descriptor ที่กำลังถูกส่งผ่านอยู่ จะถือ Reference ที่ GC ไม่ได้นับรวมไว้ ทำให้ Collector สามารถ Free Socket ที่ยังมีชีวิตอยู่จริง เหลือทิ้งไว้เป็น Dangling sk_buff ที่ยังถูกอ้างอิงถึง เปิดทางให้ผู้โจมตีจัดการหน่วยความจำที่ถูกปลดปล่อยไปแล้วเพื่อสร้าง Memory Corruption และยกระดับสิทธิ์ในที่สุด
ขอบเขตผลกระทบและสถานะการแพตช์
ช่องโหว่นี้ครอบคลุม Linux Stable ตั้งแต่เวอร์ชัน 6.12 ถึง 6.12.94 และมีความอันตรายเป็นพิเศษเนื่องจากเปิดใช้งานอยู่ในเกือบทุกการตั้งค่าเริ่มต้น ผู้ใช้ภายในระบบทั่วไป หรือ Process ที่รันอยู่ภายใน Container ที่มี Shell Access เพียงเท่านั้นก็สามารถกระตุ้นช่องโหว่นี้ได้ ทำให้เป็นทั้ง Local Privilege Escalation และ Container Escape ในตัวเดียวกัน
แพตช์ระดับ Upstream สำหรับปัญหานี้มีมาตั้งแต่เดือนพฤษภาคม 2569 โดยแก้ไขด้วยการย้ายจุดตั้งค่า gc_in_progress ให้เป็น True ภายในฟังก์ชัน unix_gc() เอง เพื่อปิดช่องว่างของ Race Condition อย่างไรก็ตาม สิ่งที่ทำให้สถานการณ์เปลี่ยนไปอย่างมีนัยสำคัญคือการที่ Exploit Code ที่ใช้งานได้จริงถูกเผยแพร่สู่สาธารณะเมื่อวันที่ 10 สิงหาคม 2569 ทำให้ช่องโหว่ที่เคยเป็นเพียงข้อบกพร่องทางทฤษฎีกลายเป็นความเสี่ยงที่จับต้องได้ทันที แม้ ณ วันที่ 27 สิงหาคม 2569 จะยังไม่มีรายงานยืนยันการถูกโจมตีจริงในวงกว้างก็ตาม
ระบบที่ได้รับผลกระทบ
- Linux Kernel Stable เวอร์ชัน 6.12 ถึง 6.12.94 ที่ยังไม่ได้อัปเดตเป็น 6.12.95 หรือรุ่นที่มีแพตช์
- ระบบที่ใช้งาน Container (Docker, Kubernetes และแพลตฟอร์ม Container อื่น) บน Kernel รุ่นที่ได้รับผลกระทบ โดยเฉพาะ Multi-tenant Environment ที่ Container หลายรายใช้ Kernel ร่วมกัน
- ระบบ CloudLinux 10 และ Distribution อื่นที่ใช้ Kernel ในช่วงเวอร์ชันที่ระบุ ตามที่ผู้ให้บริการ Distribution ยืนยันความเสี่ยง
ผลกระทบที่อาจเกิดขึ้น
- ผู้ใช้ภายใน Container ที่ไม่มีสิทธิ์พิเศษสามารถยกระดับเป็น Root บน Host ได้ ทำลายขอบเขตการแยก Isolation ซึ่งเป็นหลักการพื้นฐานที่สุดของสถาปัตยกรรม Container
- เนื่องจากช่องโหว่เปิดใช้งานในเกือบทุก Configuration เริ่มต้น องค์กรที่ใช้ Container บน Kernel รุ่นที่ได้รับผลกระทบมีความเสี่ยงในวงกว้าง โดยไม่จำเป็นต้องมีการตั้งค่าพิเศษใดๆ เพื่อให้ช่องโหว่ทำงานได้
- การมี Exploit Code สาธารณะที่ใช้งานได้จริง เพิ่มโอกาสที่จะถูกนำไปใช้โจมตีอย่างมีนัยสำคัญ แม้ยังไม่พบการโจมตีจริงในวงกว้าง ณ ขณะนี้ แต่สถานการณ์อาจเปลี่ยนแปลงได้อย่างรวดเร็ว
- ผลกระทบรุนแรงเป็นพิเศษสำหรับผู้ให้บริการ Cloud/Hosting ที่พึ่งพา Container Isolation เป็นกลไกความปลอดภัยหลักในการแยกลูกค้าหลายรายบน Infrastructure เดียวกัน
สิ่งที่องค์กรควรทำ
- ตรวจสอบเวอร์ชัน Kernel ที่ใช้งานอยู่ทั้งหมด หากอยู่ในช่วง Linux Stable 6.12 ถึง 6.12.94 ให้อัปเดตเป็น 6.12.95 หรือรุ่นที่มีแพตช์โดยเร็วที่สุด
- Reboot ระบบหลังอัปเดต Kernel เนื่องจากการแพตช์ระดับ Kernel จำเป็นต้องรีสตาร์ทระบบเพื่อให้มีผลใช้งานจริง ไม่สามารถ Hot-patch ได้ในทุกกรณี
- สำหรับระบบที่ยังไม่สามารถอัปเดตได้ทันที ควรจำกัดสิทธิ์และการเข้าถึง Container ให้เข้มงวดที่สุดเท่าที่ทำได้ ระหว่างรอการแพตช์ เช่น การใช้ Seccomp Profile หรือ AppArmor/SELinux เพิ่มเติม
- ตรวจสอบ Distribution และผู้ให้บริการ Cloud ที่องค์กรใช้งานว่าได้เผยแพร่ Kernel Update ที่แก้ไขปัญหานี้แล้วหรือไม่ โดยเฉพาะระบบที่ใช้ Managed Kubernetes หรือ Container Service
แนวทางลดความเสี่ยงระยะยาว
1. จัดทำกระบวนการตรวจสอบและอัปเดต Kernel อย่างสม่ำเสมอ โดยเฉพาะสำหรับ Container Host
เนื่องจากช่องโหว่ระดับ Kernel ที่กระทบ Container Isolation มีความรุนแรงสูงกว่าช่องโหว่ระดับ Application ทั่วไป ควรมีรอบการ Patch ที่รวดเร็วเป็นพิเศษ
2. เสริมการป้องกันหลายชั้นสำหรับ Container นอกเหนือจาก Kernel Isolation เพียงอย่างเดียว
เช่น การใช้ gVisor, Kata Containers หรือ MicroVM สำหรับ Workload ที่มีความอ่อนไหวสูง ซึ่งลดการพึ่งพา Kernel ร่วมกันระหว่าง Container และ Host
3. ติดตามการเผยแพร่ Exploit Code สาธารณะสำหรับช่องโหว่ Kernel ที่ยังไม่ได้แพตช์ในองค์กร
เนื่องจากช่วงเวลาระหว่างการเผยแพร่แพตช์กับการเผยแพร่ Exploit Code สาธารณะเป็นตัวบ่งชี้สำคัญของความเร่งด่วนในการดำเนินการ
4. จำกัดสิทธิ์ของ Process ภายใน Container ตามหลัก Least Privilege
ลดความเสี่ยงและผลกระทบหากมีการ Exploit ช่องโหว่ระดับ Kernel สำเร็จ แม้จะไม่สามารถป้องกันช่องโหว่ได้โดยตรงก็ตาม
วิเคราะห์ในมุมมองจาก TXEC
CVE-2026-53361 เป็นตัวอย่างที่ชัดเจนของความเสี่ยงเชิงโครงสร้างในสถาปัตยกรรม Container ที่พึ่งพา Kernel เดียวกันระหว่าง Host และ Container ทั้งหมด แม้ Container จะให้ความรู้สึกเหมือนเป็นสภาพแวดล้อมที่แยกจากกันอย่างสมบูรณ์ แต่ในทางเทคนิคแล้วยังคงใช้ Kernel เดียวกัน ทำให้ช่องโหว่ระดับ Kernel เช่นนี้สามารถทำลายขอบเขตการแยกทั้งหมดได้ในคราวเดียว
TXEC มองว่าจุดที่องค์กรควรให้ความสำคัญเป็นพิเศษคือช่วงเวลาที่แพตช์ Upstream มีมาตั้งแต่เดือนพฤษภาคม แต่ Exploit Code สาธารณะเพิ่งปรากฏในเดือนสิงหาคม ซึ่งเป็นรูปแบบที่พบได้บ่อยขึ้นเรื่อยๆ คือช่องโหว่ที่ดูเหมือนไม่เร่งด่วนในช่วงแรกอาจกลายเป็นความเสี่ยงเร่งด่วนได้ทันทีเมื่อมีการเผยแพร่ Exploit สาธารณะ องค์กรที่ใช้ Container เป็นกลไกความปลอดภัยหลักจึงควรมีกระบวนการติดตามและอัปเดต Kernel ที่รวดเร็ว ไม่รอจนถึงรอบ Maintenance ตามปกติสำหรับช่องโหว่ที่มีลักษณะเช่นนี้
รู้ก่อน ตรวจพบเร็ว ลดความเสียหายได้มากกว่า
[ แหล่งอ้างอิง: SecurityOnline, SentinelOne, CloudLinux, GitHub Advisory Database ]