CVE-2026-19937 in Zephyr
Tóm tắt
Bởi VulDB • 13/10/2026
Lớp truy cập Bluetooth Mesh và cơ chế xử lý tin nhắn có thể trì hoãn (delayable-message machinery) trong subsys/bluetooth/mesh/delayable_msg.c quản lý một pool tĩnh gồm CONFIG_BT_MESH_ACCESS_DELAYABLE_MSG_COUNT ngữ cảnh tin nhắn (mặc định là 4), được nối vào danh sách free_ctx hoặc busy_ctx. Hàm release_delayable_msg_ctx() chỉ trả lại một ngữ cảnh về free_ctx khi sys_slist_find_and_remove() tìm thấy nó trên busy_ctx. Đường dẫn lỗi do cạn kiệt chunk trong bt_mesh_delayable_msg_manage() giải phóng một ngữ cảnh đã bị pop khỏi free_ctx nhưng chưa được chèn vào busy_ctx, khiến ngữ cảnh này không thuộc danh sách nào và bị mất vĩnh viễn khỏi pool. Vì bt_mesh_delayable_msg_init() chỉ chạy một lần từ bt_mesh_init(), và việc reset/tạm dừng node chỉ làm trống busy_ctx, nên sự mất mát này tồn tại qua quá trình unprovision, re-provision và suspend/resume — nó chỉ được xóa khi khởi động lại thiết bị.
Đường dẫn lỗi này xảy ra khi pool chunk (CONFIG_BT_MESH_ACCESS_DELAYABLE_MSG_CHUNK_COUNT, mặc định 40 chunks) thiếu các chunk mà một tin nhắn trì hoãn mới cần, và tin nhắn chờ lâu nhất không thể được flush vì bt_mesh_access_send() trả về -EBUSY hoặc -ENOBUFS (tất cả ngữ cảnh segmented-TX đang bận, hoặc bộ đệm quảng cáo/segment bị cạn kiệt). Một peer đã được provision vào mạng mesh — sở hữu NetKey hợp lệ cùng AppKey hoặc DevKey liên kết với một server model — có thể gây ra cả hai điều kiện trên bằng cách flood victim bằng các yêu cầu kích hoạt phản hồi segmented trong khi giữ lại Segment Acknowledgment, khiến các ngữ cảnh truyền tải bị chiếm dụng trong khi các phản hồi đang chờ giữ chặt pool chunk. Mỗi yêu cầu tiếp theo đến trong khoảng thời gian đó sẽ làm rò rỉ một ngữ cảnh.
Khi pool cạn kiệt, bt_mesh_delayable_msg_manage() trả về -ENOMEM cho mọi lệnh gửi tiếp theo và bt_mesh_model_send() truyền lỗi này mà không có cơ chế dự phòng sang phương thức truyền tải ngay lập tức (immediate transmit). Vì CONFIG_BT_MESH_ACCESS_DELAYABLE_MSG và CONFIG_BT_MESH_ACCESS_DELAYABLE_MSG_CTX_ENABLED đều được bật mặc định, ctx->rnd_delay sẽ được đặt cho mọi tin nhắn truy cập nhận được, khiến tất cả các phản hồi từ Configuration Server, Health Server và application server models bị loại bỏ im lặng. Node vẫn tiếp tục nhận và xử lý lưu lượng nhưng không bao giờ trả lời, gây ra tình trạng từ chối dịch vụ (DoS) kéo dài cho đến khi thiết bị được khởi động lại. Không có tác động về rò rỉ bộ nhớ, tiết lộ thông tin hay tính toàn vẹn; các bản phát hành trước đây tính toán số chunk dựa trên dung lượng buffer truyền tải thay vì độ dài payload của nó, khiến việc gây cạn kiệt pool chunk — và do đó là lỗi rò rỉ ngữ cảnh — dễ dàng hơn nhiều.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.