Eclipse ThreadX 6.5.2.202603b แก้ 3 CVE ใหม่ในโมดูลและ Module Manager
Eclipse ThreadX ออกฮอตฟิก 6.5.2.202603b แก้ CVE-2026-115653, CVE-2026-115654 และ CVE-2026-118052 ตรวจผลกระทบ เวอร์ชัน และวิธีรับมือ
Eclipse ThreadX ออกฮอตฟิก 6.5.2.202603b: สาม CVE ใหม่กระทบสิทธิ์โมดูล สแตก และการทำงานของ Module Manager
โครงการ Eclipse ThreadX เผยแพร่คำแนะนำด้านความปลอดภัยและฮอตฟิก 6.5.2.202603b สำหรับช่องโหว่หลายรายการในระบบปฏิบัติการเรียลไทม์ที่ใช้กับอุปกรณ์ฝังตัว รอบนี้มีสามรายการที่วันเปิดเผยต่อสาธารณะและวันเผยแพร่ระเบียน CVE แรกอยู่ในช่วง 48 ชั่วโมงก่อนการตรวจ ได้แก่ CVE-2026-115653, CVE-2026-115654 และ CVE-2026-118052 ทั้งสามกระทบการใช้งาน ThreadX Modules หรือ Module Manager แต่ลักษณะผลกระทบต่างกัน ผู้ดูแลเฟิร์มแวร์ควรตรวจว่าผลิตภัณฑ์ของตนเปิดใช้ส่วนดังกล่าวและใช้พอร์ตที่เกี่ยวข้องหรือไม่ก่อนประเมินความเร่งด่วน
ลำดับเวลาและขอบเขตเวอร์ชัน
คำแนะนำทั้งสามรายการของโครงการเผยแพร่ครั้งแรกบน GitHub วันที่ 1 พฤศจิกายน 2026 เวลา 17:32 UTC โดยเวลารายรายการคือ 17:32:54 สำหรับ CVE-2026-115653, 17:32:48 สำหรับ CVE-2026-115654 และ 17:32:50 สำหรับ CVE-2026-118052 นี่คือเวลาที่ตรวจยืนยันได้จากคำแนะนำของผู้พัฒนา ไม่ใช่วันที่ CVE ถูกเพิ่มเข้าแหล่งข้อมูลรอง ฮอตฟิก 6.5.2.202603b เผยแพร่วันที่ 1 พฤศจิกายน 2026 เวลา 17:34:24 UTC ตามระเบียน GitHub Releases ของโครงการ
ระเบียน CVE แรกของผู้ประสานงานระบุวันเผยแพร่ 2 พฤศจิกายน 2026 เวลา 15:10:18 UTC สำหรับ CVE-2026-115653, 15:15:38 UTC สำหรับ CVE-2026-115654 และ 14:57:27 UTC สำหรับ CVE-2026-118052 จึงต้องแยกวันเผยแพร่ CVE ออกจากวันเปิดเผยปัญหาและวันออกแพตช์อย่างชัดเจน คำแนะนำผู้พัฒนาระบุช่วงเวอร์ชันที่ได้รับผลกระทบเป็น 6.0.1 ถึง 6.5.2.202603 รวมปลายช่วง และระบุเวอร์ชันแก้ไขเป็น 6.5.2.202603b อย่างไรก็ดี การเข้าเงื่อนไขของแต่ละ CVE ยังขึ้นกับพอร์ตและการใช้โมดูลตามรายละเอียดด้านล่าง
CVE-2026-115653: สแตกของโมดูลบน Cortex-M
ปัญหานี้อยู่ในตัวจัดการ PendSV ของพอร์ต Cortex-M ที่รองรับโมดูล ระหว่างสลับเธรด โค้ดในสิทธิ์สูงบันทึกรีจิสเตอร์ผ่าน process stack pointer ของเธรดโดยไม่ตรวจว่าตำแหน่งที่จะเขียนยังอยู่ในขอบเขตสแตกหรือไม่ หากโมดูลที่ทำงานใน user mode และมีการป้องกันหน่วยความจำสามารถกำหนด stack pointer ใกล้ขอบเขตของพื้นที่ที่ตนเขียนได้ การบันทึกบริบทอาจเขียนข้อมูลลงพื้นที่ก่อนหน้าและอ่านกลับเมื่อเธรดกลับมาทำงาน คำแนะนำของโครงการอธิบายว่าปริมาณที่เกี่ยวข้องอาจถึง 9 คำหรือ 25 คำเมื่อมีหน่วยประมวลผล floating point
ขอบเขตสำคัญคือ พอร์ตโมดูล Cortex-M และโมดูลแบบ memory-protected ที่รันใน user mode ไม่ควรตีความว่าเป็นช่องโจมตีระยะไกลต่ออุปกรณ์ ThreadX ทุกตัวโดยอัตโนมัติ ฮอตฟิกเพิ่มการตรวจตำแหน่งสแตกก่อนบันทึกบริบท และใช้ kernel stack เมื่อ stack pointer ของเธรดไม่ปลอดภัย ผู้ผลิตอุปกรณ์ที่รวมพอร์ตดังกล่าวควรทดสอบเฟิร์มแวร์ที่คอมไพล์จากเวอร์ชันแก้ไขบนฮาร์ดแวร์และการตั้งค่าหน่วยความจำจริงของตน
CVE-2026-115654: ควบคุมเธรดข้ามโมดูล
คำแนะนำของโครงการระบุว่าโมดูลแบบ memory-protected ใน user mode สามารถเรียกบริการควบคุมเธรดกับเธรดที่ตนไม่ได้เป็นเจ้าของได้ เพราะตัวตรวจสอบเดิมยืนยันว่า pointer อ้างถึงเธรดที่มีอยู่ แต่ไม่ได้ตรวจความเป็นเจ้าของอย่างเพียงพอ การกระทำที่เกี่ยวข้องมีทั้ง suspend, resume, terminate, reset, เปลี่ยน priority, เปลี่ยน preemption และ time slice ตลอดจน abort การรอของเธรดอื่น ผลคือโมดูลหนึ่งอาจหยุดหรือรบกวนการจัดตารางทำงานของเธรดแอปพลิเคชันหรือโมดูลอื่นได้
เงื่อนไขการโจมตีต้องมีโค้ดโมดูลที่รันอยู่บนอุปกรณ์อยู่แล้ว ไม่ใช่การส่งคำขอจากอินเทอร์เน็ตไปยึดอุปกรณ์โดยตรง เวอร์ชัน 6.5.2.202603b เปลี่ยนตัว dispatch ให้ปฏิเสธคำสั่งควบคุมเธรดที่โมดูลผู้เรียกไม่ได้เป็นเจ้าของ โดยคืนค่า TXM_MODULE_INVALID ทีมพัฒนาควรตรวจโค้ดที่เคยพึ่งพาการควบคุมเธรดข้ามโมดูล เพราะพฤติกรรมที่ถูกปฏิเสธหลังอัปเดตอาจทำให้ต้องออกแบบกลไกประสานงานใหม่
CVE-2026-118052: ล็อกค้างหลังขนาดโมดูลล้น
Module Manager รับขนาดข้อมูลและสแตกจากส่วน preamble ของโมดูลแล้วคำนวณขนาดการจัดสรร หากค่าทำให้เกิด arithmetic overflow ตัวโหลดบางทางคืนข้อผิดพลาด TXM_MODULE_MATH_OVERFLOW โดยไม่ปล่อย mutex ของ Module Manager จากนั้นงานอื่นที่ต้องใช้ mutex เดียวกันอาจรอไม่สิ้นสุด ทั้งการโหลด เริ่ม หยุด หรือถอนโมดูล โครงการระบุว่าไม่ใช่ปัญหาอ่านหรือเขียนหน่วยความจำนอกขอบเขตในรายการนี้ แต่เป็นการทำให้บริการจัดการโมดูลหยุดทำงานจนกว่าจะรีเซ็ตระบบ
ช่องทางเข้าถึงคือโมดูลที่อุปกรณ์รับเข้าไปโหลด ไม่ใช่การโจมตีผ่านเครือข่ายโดยตรง ระบบที่ไม่ใช้ Module Manager ไม่เข้าเงื่อนไขที่คำแนะนำระบุ ฮอตฟิกเพิ่มการปล่อย mutex ในเส้นทาง overflow และตรวจค่าขนาดก่อนคำนวณ ผู้ผลิตที่ยอมรับโมดูลจากหลายแหล่งควรจำกัดความเชื่อถือของภาพโมดูลและตรวจการอัปเดตเฟิร์มแวร์ด้วย
แนวทางรับมือ
ตรวจเวอร์ชัน ThreadX ที่ฝังในเฟิร์มแวร์ รวมถึงพอร์ต Cortex-M และการเปิดใช้ Module Manager จากนั้นอัปเดตซอร์สเป็น 6.5.2.202603b และสร้างเฟิร์มแวร์ใหม่สำหรับผลิตภัณฑ์ที่เข้าเงื่อนไข อย่าสรุปจากเลขเวอร์ชันของระบบอื่นในชุด Eclipse ThreadX ว่าแก้ ThreadX แล้ว เพราะแพตช์อยู่ในองค์ประกอบและบิลด์ที่ใช้จริง หากยังออกเฟิร์มแวร์ใหม่ไม่ได้ ให้จำกัดการโหลดโมดูลจากแหล่งที่ไม่เชื่อถือและเฝ้าระวังอาการ Module Manager ค้างหรือการควบคุมเธรดผิดปกติ มาตรการชั่วคราวนี้ไม่แทนการอัปเดตเวอร์ชันแก้ไข
บันทึกประจำการตรวจควรแยกวันที่ทั้งสามประเภท: เปิดเผยครั้งแรก 1 พฤศจิกายน 2026, แพตช์ออก 1 พฤศจิกายน 2026, และ ระเบียน CVE แรก 2 พฤศจิกายน 2026 พร้อมตรวจหมายเลข CVE ให้ตรงกับคำแนะนำแต่ละฉบับ โครงการระบุว่าแพตช์มี regression test แต่บันทึกรุ่นแจ้งว่าการแก้ไขยังไม่ได้ทดสอบบนฮาร์ดแวร์จริงทุกแบบ จึงควรทดสอบตามพอร์ตและอุปกรณ์ที่องค์กรใช้งาน