NetX Duo แก้ CVE-2026-114408 ช่อง ICMPv6 ทำ IP thread หยุด
Eclipse ThreadX NetX Duo 6.5.2.202603b แก้ CVE-2026-114408 ช่อง ICMPv6 Packet Too Big เมื่อ destination table เต็ม ตรวจเงื่อนไขและวิธีรับมือ
NetX Duo 6.5.2.202603b แก้ CVE-2026-114408: ICMPv6 ทำให้ IP thread หยุดได้เมื่อ destination table เต็ม
โครงการ Eclipse ThreadX เผยแพร่ฮอตฟิก NetX Duo 6.5.2.202603b เพื่อแก้ CVE-2026-114408 ในส่วนประมวลผล ICMPv6 Packet Too Big ของเครือข่าย IPv6 ช่องโหว่นี้ทำให้โค้ดอ่าน pointer ที่เป็น NULL หลังพยายามเพิ่มรายการลง destination table แล้วล้มเหลว ผลที่ยืนยันในการทดสอบของโครงการคือ IP helper thread ล้มเมื่อมีข้อความ Packet Too Big ที่ทำให้ตารางเต็มและมีข้อความตามมาอีกหนึ่งรายการ จึงเป็นความเสี่ยงด้านความพร้อมใช้งานของอุปกรณ์ที่เปิดความสามารถเฉพาะนี้
วันเปิดเผยและเวอร์ชัน
คำแนะนำด้านความปลอดภัยของโครงการบน GitHub เผยแพร่ครั้งแรกวันที่ 1 พฤศจิกายน 2026 เวลา 17:32:46 UTC ฮอตฟิก 6.5.2.202603b เผยแพร่วันที่ 1 พฤศจิกายน 2026 เวลา 17:34:30 UTC และระเบียน CVE-2026-114408 เผยแพร่ครั้งแรกวันที่ 2 พฤศจิกายน 2026 เวลา 15:04:39 UTC วันทั้งสามตรวจจากคำแนะนำ รุ่นเผยแพร่ และระเบียน CVE ของต้นทางโดยตรง การที่ NVD เพิ่งแสดงรายการในรอบหลังไม่ใช่วันที่เปิดเผยช่องโหว่ครั้งแรก
โครงการระบุว่าเวอร์ชันที่ได้รับผลกระทบคือ 6.4.5.202504 ถึง 6.5.2.202603a รวมปลายช่วง และเวอร์ชันแก้ไขคือ 6.5.2.202603b รุ่นก่อนหรือเท่ากับ 6.4.4.202503a ยังไม่มีบล็อกโค้ดที่ก่อปัญหาซึ่งถูกเพิ่มเมื่อแก้ CVE ก่อนหน้า จึงไม่ควรเหมารวมว่า NetX Duo ทุกรุ่นที่เก่ากว่าแพตช์มีช่องโหว่เดียวกัน นอกจากนี้ ต้องเป็นบิลด์ที่เปิดทั้ง FEATURE_NX_IPV6 และ NX_ENABLE_IPV6_PATH_MTU_DISCOVERY โดยตัวเลือก Path MTU Discovery ปิดเป็นค่าเริ่มต้น บิลด์ที่ไม่เปิดตัวเลือกนี้ไม่คอมไพล์เส้นทางโค้ดที่มีปัญหา
กลไกและผลกระทบ
ฟังก์ชัน _nx_icmpv6_process_packet_too_big รับข้อความ ICMPv6 Packet Too Big แล้วนำปลายทางที่อยู่ในแพ็กเก็ตอ้างอิงไปเพิ่มใน destination table ผ่าน _nx_icmpv6_dest_table_add เมื่อเพิ่มสำเร็จ ฟังก์ชันที่ถูกเรียกจะคืน pointer ของรายการที่สร้างหรือปรับปรุง แต่เมื่อไม่มีช่องว่างหรือเพิ่ม neighbour cache entry สำหรับ next hop ไม่ได้ ฟังก์ชันจะคืน NX_NOT_SUCCESSFUL พร้อม pointer เป็น NX_NULL เส้นทางที่มีปัญหาเก็บค่าสถานะไว้แต่กลับอ่านฟิลด์ nx_ipv6_destination_entry_nd_entry ผ่าน pointer นั้นโดยไม่ตรวจผลลัพธ์ก่อน
ผู้ส่งข้อความสามารถระบุปลายทางที่แตกต่างกันใน Packet Too Big เพื่อใช้ช่องของตารางไปเรื่อย ๆ เมื่อเต็ม ข้อความถัดไปจะเข้าสู่เส้นทาง dereference ที่ผิดพลาด คำแนะนำของโครงการระบุว่า handler ยอมรับค่า MTU ที่มากกว่าศูนย์และไม่เกิน MTU ของอินเทอร์เฟซ โดยไม่ได้ตรวจ source address หรือ hop limit ในเส้นทางนี้ ค่า NX_IPV6_DESTINATION_TABLE_SIZE เริ่มต้นเป็น 8 ดังนั้นในการทดสอบของผู้พัฒนา ข้อความที่ 9 ทำให้กระบวนการ Linux port เกิด SIGSEGV; เมื่อขยายตารางเป็น 32 ข้อความที่ 33 จึงเป็นตัวกระตุ้น การขยายตารางเพิ่มจำนวนข้อความที่ต้องส่ง แต่ไม่แก้สาเหตุ
การทดสอบดังกล่าวเป็นหลักฐานบน ThreadX Linux port ไม่ใช่คำรับรองว่าฮาร์ดแวร์ฝังตัวทุกแบบจะล้มเหมือนกัน โครงการระบุด้วยว่าในเป้าหมายซึ่งอ่านหน่วยความจำใกล้ address 0 ได้ อาการอาจต่างออกไปและยังไม่ได้วัดผลในลักษณะเดียวกัน แม้เช่นนั้น การอ่าน pointer โดยไม่ตรวจสถานะยังเป็นข้อบกพร่องที่ต้องแก้ อุปกรณ์ที่ประมวลผลแพ็กเก็ตจากเครือข่ายและเปิด Path MTU Discovery มีขอบเขตการรับข้อมูลกว้างกว่าช่องโหว่ ThreadX Modules บางรายการ จึงต้องประเมินการเข้าถึงอินเทอร์เฟซ IPv6 ของอุปกรณ์จริง
วิธีรับมือสำหรับผู้ผลิตและผู้ดูแลอุปกรณ์
ตรวจซอร์สหรือ dependency ของเฟิร์มแวร์ว่าใช้ Eclipse ThreadX NetX Duo รุ่นใด และตรวจค่าคอมไพล์ FEATURE_NX_IPV6 กับ NX_ENABLE_IPV6_PATH_MTU_DISCOVERY หากเข้าเงื่อนไข ให้ดึง NetX Duo 6.5.2.202603b และสร้างเฟิร์มแวร์ใหม่จากซอร์สที่แก้แล้ว แพตช์ตรวจว่าการเพิ่ม destination entry สำเร็จก่อนใช้ pointer เมื่อเพิ่มไม่สำเร็จจะทิ้งข้อความนั้นและให้ IP thread ทำงานต่อ โครงการระบุว่าไม่มีการเปลี่ยน public API ดังนั้นโดยหลักแล้วแอปพลิเคชันไม่ต้องแก้การเรียกใช้ API เพื่อรับแพตช์
หากยังไม่สามารถออกเฟิร์มแวร์ใหม่ได้ การปิด NX_ENABLE_IPV6_PATH_MTU_DISCOVERY ตอนสร้างบิลด์จะตัดโค้ดที่มีปัญหาออกตามคำแนะนำของโครงการ แต่ต้องทดสอบผลต่อการค้นหา Path MTU ของระบบ การกรอง ICMPv6 Packet Too Big ก่อนถึงอุปกรณ์อาจตัดตัวกระตุ้นได้เช่นกัน แต่กระทบการทำงานของ Path MTU Discovery และอาจมีผลต่อการสื่อสาร IPv6 ข้อแลกเปลี่ยนนี้ควรพิจารณาเป็นรายเครือข่าย ไม่ใช่ตั้งค่าโดยไม่ทดสอบ
หลังอัปเดต ควรทดสอบการรับ ICMPv6 Packet Too Big เมื่อ destination table เต็ม รวมทั้งตรวจว่า IP thread ยังประมวลผลแพ็กเก็ตอื่นได้ โครงการมี regression test netx_icmpv6_packet_too_big_table_full_test ซึ่งเติมตาราง ส่งอีกหนึ่งข้อความ แล้วตรวจการประมวลผล Neighbor Advertisement ต่อไป การทดสอบบนพอร์ตและฮาร์ดแวร์จริงของผู้ผลิตยังจำเป็นสำหรับการยืนยันการทำงานของผลิตภัณฑ์