FreeRTOS-Kernel แก้ CVE-2026-119086 ช่อง queue sets กระทบขอบเขต MPU
FreeRTOS-Kernel V11.3.3 แก้การตรวจชนิด queue set ไม่ครบ อาจให้ unprivileged task เขียนเกินขอบเขตขณะเคอร์เนลทำงานด้วยสิทธิสูง เฉพาะ build ที่เปิด MPU และ queue sets
FreeRTOS-Kernel แก้ CVE-2026-119086: งานสิทธิต่ำอาจเขียนหน่วยความจำเกินขอบเขตผ่าน queue sets
โครงการ FreeRTOS ซึ่ง AWS ดูแลเผยแพร่ FreeRTOS-Kernel V11.3.3 เมื่อวันที่ 30 ตุลาคม 2026 เพื่อแก้ CVE-2026-119086 ช่องโหว่ในระบบ queue sets ที่ตรวจชนิดของ kernel object ไม่ครบก่อนนำไปทำงาน ในเฟิร์มแวร์ที่เปิดใช้ Memory Protection Unit (MPU) พร้อม queue sets งานที่ทำงานด้วยสิทธิต่ำอาจกระตุ้นให้เคอร์เนลเขียนข้อมูลเกินขอบเขตเป้าหมายในช่วงที่โค้ดเคอร์เนลทำงานด้วยสิทธิสูง ส่งผลต่อความถูกต้องของ privileged execution และขอบเขตการแยกงานที่ MPU ตั้งใจบังคับ
นี่เป็นช่องโหว่ที่ต้องพิจารณาตาม รูปแบบการ build ของเฟิร์มแวร์ ไม่ใช่ดูเพียงเลขรุ่น FreeRTOS-Kernel เท่านั้น ประกาศของโครงการระบุชัดว่าแอปที่ไม่ได้เปิดใช้ queue sets ไม่ได้รับผลกระทบจากรายการนี้ ผู้ดูแลผลิตภัณฑ์ฝังตัวจึงควรตรวจทั้งรุ่นของซอร์ส เงื่อนไข MPU wrappers และค่า configUSE_QUEUE_SETS ที่ถูกคอมไพล์จริง ก่อนสรุประดับความเร่งด่วนของอุปกรณ์แต่ละรุ่น
วันเปิดเผย วันเผยแพร่ CVE และวันออกแพตช์
GitHub release ทางการของ FreeRTOS-Kernel ระบุว่า V11.3.3 เผยแพร่วันที่ 30 ตุลาคม 2026 เวลา 16:52:07 UTC พร้อมการแก้ปัญหาที่เกี่ยวข้อง จึงใช้เป็นวันที่แพตช์พร้อมใช้งานจากโครงการ ระเบียน CVE Program ของ CVE-2026-119086 เผยแพร่ครั้งแรกวันที่ 30 ตุลาคม 2026 เวลา 17:33:51 UTC และ GitHub Security Advisory ของโครงการเผยแพร่เวลา 17:38:00 UTC ในวันเดียวกัน การเปิดเผยต่อสาธารณะครั้งแรกที่ตรวจยืนยันได้จึงอยู่ในวันที่ 30 ตุลาคม 2026 เช่นเดียวกับวันเผยแพร่ CVE และวันออกแพตช์ ซึ่งทั้งหมดอยู่ภายใน 48 ชั่วโมงก่อนรอบตรวจนี้
กลไกของช่องโหว่
Queue sets ใน FreeRTOS ช่วยให้งานรอเหตุการณ์จากคิวหรือ semaphore หลายรายการผ่านกลไกเดียวได้ การทำงานบางจุดต้องรับข้อมูลอ้างอิง kernel object แล้วตรวจว่า object นั้นเป็น queue set ตามชนิดที่คาดหวัง แต่ประกาศความปลอดภัยระบุว่าการตรวจชนิดไม่ครบถ้วน ใน build ที่เปิด MPU และ queue sets งานที่ไม่มีสิทธิพิเศษอาจนำข้อมูลอ้างอิงที่ไม่ตรงชนิดเข้าสู่การดำเนินการของ queue set ได้
เมื่อเคอร์เนลนำข้อมูลดังกล่าวไปใช้ภายใต้สิทธิ privileged การเขียนอาจเลยขอบเขตหน่วยความจำที่ตั้งใจไว้ ผลกระทบที่ต้นทางยืนยันคือความถูกต้องของการทำงานด้วยสิทธิสูงและแนวแบ่งแยกระหว่าง unprivileged task กับเคอร์เนลอาจถูกกระทบ ประกาศไม่ได้ระบุว่าทุกกรณีจะนำไปสู่การรันโค้ดตามใจหรือการโจมตีระยะไกล จึงไม่ควรขยายผลไปไกลกว่าข้อมูลที่ผู้พัฒนายืนยัน
ต้นทางยังเจาะจงว่าเงื่อนไขคือ MPU-enabled builds ที่ใช้ queue sets โดยช่วงรุ่นที่ได้รับผลกระทบคือ V7.4.0 ถึง V11.3.2 เมื่อใช้ MPU wrappers และตั้งค่า configUSE_QUEUE_SETS=1 หากอุปกรณ์ไม่ได้เปิด queue sets ตามประกาศจะไม่อยู่ในขอบเขตของช่องโหว่นี้ แม้จะใช้ซอร์ส FreeRTOS-Kernel ที่อยู่ในช่วงรุ่นเดียวกันก็ตาม อย่างไรก็ดี การตรวจเพียงไฟล์ตั้งค่าใน repository อาจไม่พอสำหรับผลิตภัณฑ์ที่มีหลาย target หรือหลาย build profile; ต้องตรวจ artifact ที่ deploy จริง
รุ่นแก้ไขและการนำแพตช์ไปใช้
FreeRTOS-Kernel V11.3.3 เป็นรุ่นที่แก้ CVE-2026-119086 แล้ว AWS และโครงการแนะนำให้อัปเกรดเป็น V11.3.3 หรือใหม่กว่า จากนั้น rebuild และ reflash เฟิร์มแวร์ ที่ได้รับผลกระทบ การอัปเดตซอร์สในระบบ build โดยไม่สร้าง binary ใหม่ หรือสร้างใหม่แต่ยังไม่ส่งไปยังอุปกรณ์ที่ใช้งานจริง ไม่ได้เปลี่ยนความเสี่ยงของอุปกรณ์นั้น
สำหรับองค์กรที่ใช้ fork หรือโค้ดดัดแปลงของ FreeRTOS-Kernel ให้ตรวจว่าการแก้ใน V11.3.3 ถูกนำเข้า branch ของตนอย่างถูกต้อง และทดสอบการทำงานของ queue sets บนพอร์ตและ MCU ที่ใช้งานจริง หากผลิตภัณฑ์รวม FreeRTOS ผ่าน SDK ของผู้ผลิตชิปหรือชุดพัฒนาอีกชั้น ต้องตรวจรุ่น FreeRTOS-Kernel ภายในแพ็กเกจดังกล่าวและกำหนดแผนรับแพตช์จากผู้จัดจำหน่ายด้วย ไม่ควรใช้ชื่อรุ่นของ SDK ชั้นนอกแทนเลขรุ่นเคอร์เนลโดยไม่มีหลักฐาน
การคัดกรองอุปกรณ์และมาตรการระหว่างรออัปเดต
ทีมเฟิร์มแวร์ควรเริ่มจาก inventory ของผลิตภัณฑ์และ build configuration: ระบุรุ่น FreeRTOS-Kernel, เปิด MPU หรือไม่, ใช้ MPU wrappers หรือไม่ และค่า configUSE_QUEUE_SETS ของแต่ละ image จากนั้นจัดลำดับอุปกรณ์ที่อยู่ในช่วง V7.4.0–V11.3.2 และเปิดทั้ง MPU กับ queue sets ให้รับแพตช์ก่อน ระบบที่ปิด queue sets ไม่ได้รับผลจากช่องโหว่นี้ตาม advisory แต่ควรเก็บหลักฐานการตั้งค่าที่ใช้ตัดสินไว้สำหรับการตรวจย้อนหลัง
ในช่วงที่ยัง reflash ไม่ครบ อาจลดการเปิดรับข้อมูลที่ unprivileged task ใช้ควบคุมการทำงานของ queue set ตามสถาปัตยกรรมของผลิตภัณฑ์ แต่การแก้ที่ผู้พัฒนาระบุคือการอัปเกรด ไม่ใช่การหวังพึ่งมาตรการชั่วคราว หลัง deploy ให้ตรวจเวอร์ชันและ hash ของ image ที่อยู่บนอุปกรณ์จริง ทดสอบการแยกสิทธิของงานกับ queue sets และติดตามอาการผิดปกติ เช่น การรีเซ็ตหรือความเสียหายของข้อมูลที่เกี่ยวข้องกับเส้นทางนี้โดยไม่สรุปว่าเป็นการโจมตีจนกว่าจะมีหลักฐานสนับสนุน