นักวิจัยด้านความปลอดภัยเปิดเผยช่องโหว่ใหม่ 4 รายการใน Linux Kernel ที่เกี่ยวข้องกับ Networking Subsystems หลายจุด ได้แก่ CVE-2026-80844 (DirtyAH6), CVE-2026-81000 (TUNderflow), CVE-2026-68121 (PPPoEject) และ CVE-2026-74469 (DiagSpill) ซึ่งอาจทำให้ผู้โจมตีที่มี Local Access เกิด Kernel Memory Corruption และยกระดับสิทธิ์เป็น Root ได้สำเร็จ ทั้งนี้ช่องโหว่ทั้งหมดได้รับการแก้ไขแล้วใน Linux Stable Branches หลายเวอร์ชัน หลังจากถูกรายงานผ่านกระบวนการ Coordinated Disclosure ตั้งแต่กลางเดือนกรกฎาคม 2569
รายละเอียดการโจมตี
CVE-2026-80844 (DirtyAH6): ช่องโหว่ใน IPv6 Authentication Header
DirtyAH6 เกิดจากการที่ Kernel จัดการค่า IPv6 Routing Header ที่ผิดรูปแบบโดยไม่ตรวจสอบฟิลด์ segments_left อย่างถูกต้อง ในกระบวนการประมวลผล IPv6 Authentication Header (AH) ภายในโค้ด IPsec/XFRM ทำให้เกิดการเลื่อนตำแหน่ง Pointer ออกนอกขอบเขตหน่วยความจำที่ตั้งใจไว้ (Out-of-Bounds Memory Operation) ช่องโหว่นี้สามารถนำไปสู่การยกระดับสิทธิ์เป็น Root ในกรณีที่ผู้โจมตีควบคุม Network Namespace ได้ และยังอาจก่อให้เกิด Denial of Service จากระยะไกลสำหรับอุปกรณ์ Router หรือ Gateway ที่ใช้ IPv6 AH ในโหมด Transport นักวิจัยสาธิตให้เห็นการยึดสิทธิ์ Root จากระยะไกลได้ในห้องทดลองด้วยเทคนิค Memory Grooming แม้จะระบุว่าการโจมตีแบบ Remote-Only ในสภาพแวดล้อมจริงทำได้ยากมาก
CVE-2026-81000 (TUNderflow): Integer Underflow ใน TUN/TAP
TUNderflow เป็นช่องโหว่ประเภท Integer Underflow ที่นำไปสู่การอ่านหรือเขียนข้อมูลนอกขอบเขตหน่วยความจำ (Out-of-Bounds Read/Write) ในระบบ TUN/TAP ซึ่งเป็น Virtual Network Device Subsystem ของ Linux ผู้ใช้ระดับ Local ที่มีเจตนาร้ายสามารถใช้ประโยชน์จากค่า Receive-Headroom ที่มีขนาดเกินปกติผ่านการตั้งค่า Network Device รวมถึงเส้นทางที่เกี่ยวข้องกับ Open vSwitch ทำให้เกิด Integer Underflow ระหว่างกระบวนการจัดสรร Socket-Buffer
CVE-2026-68121 (PPPoEject): Use-After-Free ใน PPPoE
PPPoEject เป็นช่องโหว่ประเภท Use-After-Free ที่เกิดขึ้นในฟังก์ชัน pppoe_sendmsg() ของระบบ PPP over Ethernet (PPPoE) ปัญหาเกิดจากฟังก์ชันนี้เก็บ Pointer ที่ชี้ไปยัง PPPoE Header ไว้ ขณะเดียวกันก็เรียกใช้ฟังก์ชันจัดการ Device Header ระดับล่างที่อาจทำการ Reallocate Socket Buffer ใหม่ ทำให้ Pointer เดิมกลายเป็น Pointer ที่ไม่ถูกต้องอีกต่อไป (Invalidated) และเปิดทางให้ผู้โจมตีเขียนทับหน่วยความจำ Kernel ที่ถูกปล่อยคืนไปแล้ว ช่องโหว่นี้ต้องการเพียง Local Access ในการใช้ประโยชน์
CVE-2026-74469 (DiagSpill): Buffer Overflow ใน SCTP Diagnostic
DiagSpill เป็นช่องโหว่ Buffer Overflow ที่เกิดจากปัญหา Counter Wraparound ในกลไกการรายงานข้อมูลวินิจฉัย (Diagnostic Reporting) ของ SCTP ผ่าน sock_diag โดย SCTP Association รองรับ Peer Transport ได้สูงสุดถึง 65,536 รายการ แต่ตัวนับ (Counter) ที่ใช้ในระบบมีขนาดเพียง 16 บิต เมื่อจำนวน Peer Transport ถึงขีดจำกัดนี้ ตัวนับจะ "วนกลับไปเป็นศูนย์" (Wraps to Zero) ทำให้ระบบจองพื้นที่หน่วยความจำไม่เพียงพอ และเกิดการเขียนข้อมูลเกินขอบเขตของ Netlink Response Buffer ที่ตั้งใจไว้อย่างมาก จุดที่น่ากังวลเป็นพิเศษคือช่องโหว่นี้ไม่ต้องการ Unprivileged User Namespace หรือ Capability พิเศษใดๆ เพียงระบบเปิดใช้งาน SCTP และ sctp_diag เท่านั้น
เวอร์ชัน Kernel ที่ได้รับการแก้ไขแล้ว
ช่องโหว่ทั้ง 4 รายการได้รับการแก้ไขในเวอร์ชัน Linux Stable Branches แรกที่รวมการแก้ไขไว้แล้ว ได้แก่ 5.10.270, 5.15.221, 6.1.188, 6.6.157, 6.12.109, 6.18.50 และ 7.2.4 โดยกระบวนการเปิดเผยช่องโหว่เป็นไปตามแนวทาง Coordinated Disclosure ซึ่งนักวิจัยรายงานช่องโหว่ครั้งแรกตั้งแต่กลางเดือนกรกฎาคม 2569 ก่อนที่จะมีการเผยแพร่ Patch และรายละเอียดทางเทคนิคต่อสาธารณะ
ผลกระทบที่อาจเกิดขึ้น
1. ความเสี่ยงกว้างขวางเนื่องจาก Linux ถูกใช้งานแพร่หลายทั้ง Server และ Infrastructure
เนื่องจาก Linux Kernel เป็นรากฐานของระบบปฏิบัติการที่ใช้งานอย่างแพร่หลายในเซิร์ฟเวอร์ Container, Cloud Infrastructure และอุปกรณ์เครือข่าย ช่องโหว่ที่เกี่ยวข้องกับ Networking Subsystems ซึ่งเป็นส่วนประกอบพื้นฐานที่ใช้งานทั่วไป จึงมีขอบเขตผลกระทบที่กว้างขวางกว่าช่องโหว่ในซอฟต์แวร์เฉพาะทาง
2. ความเสี่ยงเพิ่มขึ้นในสภาพแวดล้อม Multi-Tenant และ Container
ช่องโหว่ที่ต้องการเพียง Local Access เช่น TUNderflow และ PPPoEject มีความเสี่ยงสูงเป็นพิเศษในสภาพแวดล้อมที่มีผู้ใช้หลายคนหรือ Container หลายตัวใช้ Kernel ร่วมกัน เนื่องจากผู้โจมตีที่สามารถเข้าถึง Container หรือ Tenant หนึ่งอาจใช้ช่องโหว่นี้เพื่อยกระดับสิทธิ์และหลุดออกจากขอบเขตที่ควรถูกจำกัดไว้
3. ความเสี่ยงเฉพาะเจาะจงต่อระบบที่เปิดใช้ SCTP
CVE-2026-74469 (DiagSpill) มีความเสี่ยงเฉพาะเจาะจงสูงเนื่องจากไม่ต้องการ Capability พิเศษใดๆ องค์กรที่มีระบบเปิดใช้งาน SCTP ซึ่งมักพบในระบบโทรคมนาคมและระบบที่ต้องการ Reliable Multi-Stream Communication จึงมีความเสี่ยงสูงกว่าระบบทั่วไปที่ไม่ได้เปิดใช้ Protocol นี้
4. ความเสี่ยงต่อ Router และ Gateway ที่ใช้ IPv6 AH
CVE-2026-80844 (DirtyAH6) ส่งผลกระทบเป็นพิเศษต่ออุปกรณ์ Router หรือ Gateway ที่ใช้งาน IPv6 Authentication Header ในโหมด Transport ซึ่งอาจเผชิญความเสี่ยง Denial of Service จากระยะไกล นอกเหนือจากความเสี่ยง Local Privilege Escalation
สิ่งที่องค์กรควรทำ
1. อัปเดต Linux Kernel เป็นเวอร์ชัน Stable ล่าสุดที่แก้ไขช่องโหว่แล้ว
องค์กรควรอัปเดต Linux Kernel เป็นเวอร์ชัน 5.10.270, 5.15.221, 6.1.188, 6.6.157, 6.12.109, 6.18.50 หรือ 7.2.4 ขึ้นไป ตามสายเวอร์ชันที่ใช้งานอยู่ โดยควรตรวจสอบกับ Distribution ของตนเองว่าได้รวม Patch เหล่านี้เข้าไปในเวอร์ชันที่เผยแพร่แล้วหรือยัง
2. จัดลำดับความสำคัญของระบบที่เปิดใช้ SCTP, TUN/TAP หรือ IPv6 AH
ระบบที่เปิดใช้งาน Protocol หรือฟีเจอร์ที่เกี่ยวข้องกับช่องโหว่โดยตรง เช่น SCTP, sctp_diag, TUN/TAP หรือ IPv6 Authentication Header ควรได้รับการแพตช์เป็นลำดับแรก เนื่องจากมีความเสี่ยงสูงกว่าระบบที่ไม่ได้เปิดใช้ฟีเจอร์เหล่านี้
3. จำกัดสิทธิ์ Local Access และการเข้าถึง Network Namespace
เนื่องจากช่องโหว่ส่วนใหญ่ต้องการ Local Access หรือความสามารถในการควบคุม Network Namespace องค์กรควรจำกัดผู้ใช้และ Process ที่สามารถเข้าถึงสิทธิ์เหล่านี้ให้น้อยที่สุดเท่าที่จำเป็น โดยเฉพาะในสภาพแวดล้อม Multi-Tenant หรือ Shared Infrastructure
4. ตรวจสอบสภาพแวดล้อม Container และ Multi-Tenant ที่ใช้ Kernel ร่วมกัน
องค์กรที่ใช้งาน Container Orchestration Platform ควรตรวจสอบว่า Container Runtime และการตั้งค่า Security Context จำกัดความสามารถของ Container ในการเข้าถึง Networking Subsystems ที่เกี่ยวข้องกับช่องโหว่เหล่านี้อย่างเหมาะสม เพื่อลดโอกาสที่ Container หนึ่งจะใช้ช่องโหว่นี้ยกระดับสิทธิ์และกระทบ Container อื่น
แนวทางลดความเสี่ยงระยะยาว
1. จัดทำกระบวนการติดตาม Linux Kernel Security Advisory อย่างเป็นระบบ
องค์กรที่พึ่งพา Linux เป็นระบบปฏิบัติการหลักควรจัดทำกระบวนการติดตามประกาศความปลอดภัยของ Linux Kernel และ Distribution ที่ใช้งานอย่างเป็นระบบ เพื่อให้สามารถประเมินผลกระทบและวางแผนแพตช์ได้อย่างทันท่วงทีเมื่อมีช่องโหว่ใหม่ถูกเปิดเผย
2. ลดพื้นผิวการโจมตีด้วยการปิดใช้งาน Kernel Module ที่ไม่จำเป็น
ระบบที่ไม่จำเป็นต้องใช้งาน Protocol หรือฟีเจอร์อย่าง SCTP, TUN/TAP หรือ IPv6 AH ควรพิจารณาปิดการใช้งาน Kernel Module ที่เกี่ยวข้องเพื่อลดพื้นผิวการโจมตี (Attack Surface) โดยรวม ซึ่งเป็นแนวทางป้องกันเชิงลึกที่ช่วยลดความเสี่ยงจากช่องโหว่ในอนาคตที่อาจเกี่ยวข้องกับ Component เดียวกัน
3. ใช้เครื่องมือ Runtime Security Monitoring สำหรับ Kernel-Level Threats
องค์กรควรพิจารณาติดตั้งเครื่องมือ Runtime Security ที่สามารถตรวจจับพฤติกรรมผิดปกติในระดับ Kernel เช่น ความพยายาม Memory Corruption หรือการเข้าถึง Networking Subsystems ในรูปแบบที่ผิดปกติ เพื่อเพิ่มความสามารถในการตรวจจับการโจมตีที่อาจใช้ประโยชน์จากช่องโหว่ที่ยังไม่ถูกค้นพบ (Zero-Day)
4. ทดสอบกระบวนการแพตช์ Kernel ในสภาพแวดล้อม Non-Production ก่อนใช้งานจริง
เนื่องจากการอัปเดต Kernel อาจส่งผลกระทบต่อความเข้ากันได้ของระบบและแอปพลิเคชันที่ทำงานอยู่ องค์กรควรมีกระบวนการทดสอบการแพตช์ Kernel ในสภาพแวดล้อม Non-Production ก่อนนำไปใช้งานจริง เพื่อให้สามารถแพตช์ช่องโหว่ระดับ Critical ได้อย่างรวดเร็วโดยไม่กระทบต่อความต่อเนื่องทางธุรกิจ
วิเคราะห์ในมุมมองจาก TXEC
ช่องโหว่ทั้ง 4 รายการนี้เป็นตัวอย่างที่ชัดเจนว่า Networking Subsystems ของ Linux Kernel ซึ่งเป็นโค้ดที่ผ่านการใช้งานและตรวจสอบมาอย่างยาวนาน ยังคงมีจุดอ่อนที่ละเอียดอ่อนซ่อนอยู่ ตั้งแต่การตรวจสอบ Header ที่ไม่รัดกุม ไปจนถึง Counter ขนาดเล็กเกินไปสำหรับค่าที่เป็นไปได้จริง สิ่งที่ TXEC เห็นว่าน่าสนใจเป็นพิเศษคือ CVE-2026-74469 (DiagSpill) ที่ไม่ต้องการ Capability พิเศษใดๆ เลย ซึ่งลดเงื่อนไขการโจมตีลงอย่างมากเมื่อเทียบกับช่องโหว่ Local Privilege Escalation ทั่วไปที่มักต้องการเงื่อนไขเพิ่มเติม
องค์กรในประเทศไทยที่ใช้งาน Linux เป็นระบบปฏิบัติการหลักสำหรับ Server, Container หรือ Cloud Infrastructure ควรให้ความสำคัญกับการแพตช์ Kernel อย่างสม่ำเสมอ แม้ช่องโหว่เหล่านี้จะต้องการ Local Access เป็นส่วนใหญ่ซึ่งอาจดูเหมือนมีความเสี่ยงต่ำกว่าช่องโหว่ Remote Unauthenticated แต่ในความเป็นจริง สภาพแวดล้อม Cloud และ Container สมัยใหม่ที่มีผู้ใช้และ Workload จำนวนมากใช้ Kernel ร่วมกัน ทำให้ "Local Access" ไม่ใช่เงื่อนไขที่หายากอย่างที่คิด การจัดลำดับความสำคัญของการแพตช์ตามฟีเจอร์ที่เปิดใช้งานจริงในองค์กรจึงเป็นแนวทางที่มีประสิทธิภาพมากกว่าการรอแพตช์ตามรอบปกติ รู้ก่อน ตรวจพบเร็ว ลดความเสียหายได้มากกว่า
[ แหล่งอ้างอิง: Cyber Security News ]