ช่องโหว่ Security Vulnerability — CVE-2026-85035 (CVSS 8.8)

📋 สรุปช่องโหว่

ช่องโหว่ Security Vulnerability ถูกค้นพบและรายงานใน NVD โดยมี CVSS Score 8.8 ระดับ "สูง"

รายละเอียดต้นฉบับ (EN): The can_add_rx_filter_msgq() system call installs a CAN RX filter whose callback (can_msgq_put() in drivers/can/can_common.c) is handed the caller's struct k_msgq * as user_data. The controller driver stores that raw pointer in its filter table and dereferences it from the RX path every time a match

ผู้ดูแลระบบที่ใช้ซอฟต์แวร์ที่ได้รับผลกระทบควรตรวจสอบและอัพเดตโดยเร็ว

💥 ผลกระทบที่อาจเกิดขึ้น

ผลกระทบขึ้นอยู่กับประเภทและบริบทการใช้งาน:

• ระดับความรุนแรง CVSS 8.8 (สูง) บ่งชี้ว่าช่องโหว่นี้อาจส่งผลต่อความปลอดภัยของระบบในระดับสูง
• ผู้โจมตีอาจใช้ประโยชน์จากช่องโหว่นี้เพื่อเข้าถึง แก้ไข หรือทำลายข้อมูลในระบบ
• ดูรายละเอียดผลกระทบเฉพาะที่ https://nvd.nist.gov/vuln/detail/CVE-2026-85035

🖥️ ซอฟต์แวร์และระบบที่ได้รับผลกระทบ

ตรวจสอบเวอร์ชันที่ได้รับผลกระทบและข้อมูลเพิ่มเติมที่ https://nvd.nist.gov/vuln/detail/CVE-2026-85035

🔧 แนวทางการแก้ไขและป้องกัน

• ขั้นตอนแก้ไขทั่วไป:
• 1. ตรวจสอบ Vendor Advisory: เข้าไปที่เว็บไซต์ vendor หรือ https://nvd.nist.gov/vuln/detail/CVE-2026-85035 เพื่อดู patch อย่างเป็นทางการ
• 2. อัพเดตเป็นเวอร์ชันล่าสุด: ติดตั้งเวอร์ชันที่แก้ไขช่องโหว่แล้วทันที
• 3. ตรวจสอบ Logs: ดู system log และ access log หาร่องรอยการโจมตีที่อาจเกิดขึ้นแล้ว
• 4. ติดตั้ง Security Monitoring: ใช้ WAF หรือ IDS เพื่อ monitor การโจมตี
• 5. Backup ข้อมูล: สำรองข้อมูลสำคัญก่อนทำการเปลี่ยนแปลงใดๆ
• 6. แจ้งทีมงาน: แจ้งให้ทีม IT security ทราบเพื่อวางแผนรับมือ

📄 รายละเอียดต้นฉบับ (ภาษาอังกฤษ)

The can_add_rx_filter_msgq() system call installs a CAN RX filter whose callback (can_msgq_put() in drivers/can/can_common.c) is handed the caller's struct k_msgq * as user_data. The controller driver stores that raw pointer in its filter table and dereferences it from the RX path every time a matching frame arrives. The system call verifier z_vrfy_can_add_rx_filter_msgq() in drivers/can/can_handlers.c validated the queue only with K_SYSCALL_OBJ(), which is a point-in-time check of type, initialization and caller permission and says nothing about the object's lifetime. On a build with CONFIG_USERSPACE=y and CONFIG_DYNAMIC_OBJECTS=y, an unprivileged user-mode thread that has been granted access to a CAN device can obtain a message queue whose lifetime it fully controls: k_object_alloc(K_OBJ_MSGQ) followed by k_msgq_alloc_init(). The lifetime of such an object is driven solely by its permission bitmask, and a pointer retained by the kernel is not represented there. After registering the filter, the thread calls k_object_release() — or simply terminates — and unref_check() frees the struct k_msgq storage while the CAN driver still holds the pointer. The next matching CAN frame causes k_msgq_put() to run in supervisor context against freed memory that the attacker can have groomed with another kernel allocation: the frame payload is memcpy()d through the reused block's write_ptr, and the queue's wait_q (and poll_events under CONFIG_POLL) list nodes are manipulated. This yields kernel-heap corruption reachable from a user-mode thread, defeating the isolation CONFIG_USERSPACE is intended to provide; the same dangling pointer also arises benignly when an application thread exits without calling can_remove_rx_filter(). The fix validates the queue with K_SYSCALL_OBJ_STATIC(), which additionally rejects objects carrying K_OBJ_FLAG_ALLOC, so only statically defined queues (CAN_MSGQ_DEFINE()) may be registered from user mode. Supervisor-mode callers bypass the verifier and must themselves keep the queue valid until the filter is removed.

🔗 แหล่งอ้างอิง