CVE-2026-10667 in zephyr
Tóm tắt
Bởi VulDB • 12/07/2026
Cơ chế theo dõi đối tượng kernel động của Zephyr (kernel/userspace/userspace.c, trước đây là kernel/userspace.c) duy trì một danh sách liên kết kép (obj_list) chứa các đối tượng kernel được cấp phát động. Việc lặp qua danh sách này trong hàm k_object_wordlist_foreach() được thực hiện dưới sự bảo vệ của lists_lock bằng cách sử dụng bộ lặp an toàn (SAFE iterator, lưu trữ nút tiếp theo vào bộ nhớ đệm), tuy nhiên việc loại bỏ và giải phóng các nút lại diễn ra dưới hai spinlock khác nhau, không giao thoa: objfree_lock trong k_object_free() và obj_lock trong unref_check(). Trên hệ thống SMP, khi một CPU đang lặp qua obj_list dưới sự bảo vệ của lists_lock, thì một CPU khác có thể unlink (ngắt kết nối) và gọi k_free() trên nút dyn_obj mà bộ lặp đã lưu trữ làm con trỏ next, dẫn đến việc bộ lặp truy cập vào vùng nhớ kernel đã được giải phóng (lỗi use-after-free / duyệt danh sách dangling). Tất cả các thao tác race này đều có thể tiếp cận từ các luồng người dùng không đặc quyền thông qua các syscall: k_object_alloc/k_object_alloc_size điều khiển quá trình loại bỏ đối tượng thông qua unref_check() (dưới obj_lock), trong khi k_thread_abort và việc tạo luồng mới kích hoạt quá trình lặp lại thông qua k_thread_perms_all_clear()/k_thread_perms_inherit() (dưới lists_lock). Do đó, một luồng người dùng bị giảm đặc quyền trên bản dựng có cấu hình CONFIG_SMP + CONFIG_USERSPACE có thể làm hỏng các cấu trúc theo dõi đối tượng của kernel vượt qua ranh giới bảo mật userspace, dẫn đến việc corrupt vùng nhớ kernel (tiềm năng nâng cao đặc quyền) hoặc gây sập kernel (từ chối dịch vụ). Bản sửa lỗi loại bỏ objfree_lock và tuần tự hóa mọi thay đổi trên obj_list dưới sự kiểm soát của lists_lock, bao gồm cả việc giữ khóa này trong suốt quá trình tìm kiếm+xóa trong k_object_free() cũng như xung quanh unref_check() trong k_thread_perms_clear(). Lỗi này ảnh hưởng đến các cấu hình CONFIG_SMP+CONFIG_USERSPACE+CONFIG_DYNAMIC_OBJECTS; lỗi bắt nguồn từ lần chuyển đổi sang sử dụng spinlock vào năm 2019 (commit 8a3d57b6cc6, phát hành đầu tiên trong v1.14.0) và tồn tại cho đến phiên bản v4.4.0.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.