CVE-2026-19740 in Zephyr
Tóm tắt
Bởi VulDB • 11/10/2026
Hàm triển khai Link Layer Control Procedure (LLCP) của bộ điều khiển Bluetooth LE Zephyr giữ lại nút nhận đã xử lý LL_PHY_UPDATE_IND được chấp nhận để sau đó có thể tái sử dụng cho thông báo đến host khi thời điểm cập nhật diễn ra (llcp_rx_node_retain() trong subsys/bluetooth/controller/ll_sw/ull_llcp.c, và nút này cố ý không được thu hồi lại khi đánh dấu NODE_RX_TYPE_RETAIN). Các nhánh PDU không hợp lệ của llcp_lp_pu_rx() và llcp_rp_pu_rx() trong subsys/bluetooth/controller/ll_sw/ull_llcp_phy.c hoàn tất thủ tục thông qua llcp_lr_complete()/llcp_rr_complete() mà không giải phóng nút đã giữ lại trước đó, do đó ngữ cảnh thủ tục — tham chiếu duy nhất còn lại đến nút này — bị hủy cấp phát (freed) trong khi nút vẫn đang được giữ ngoài pool nhận.
Một thiết bị ngang hàng trên kết nối LE đã thiết lập có thể khai thác lỗ hổng này một cách xác định và không cần ghép đôi hoặc mã hóa. Đối với thiết bị ngoại vi, nó gửi LL_PHY_REQ, nhận LL_PHY_RSP, sau đó gửi một LL_PHY_UPDATE_IND hợp lệ với thời điểm cập nhật ở vài sự kiện kết nối trong tương lai (khiến nút trở thành được giữ lại), rồi trước khi thời điểm này đến, gửi bất kỳ PDU Điều khiển LL nào khác như LL_LENGTH_REQ; ull_cp_rx() định tuyến nó sang thủ tục Cập nhật PHY từ xa đang hoạt động, dẫn vào nhánh PDU không hợp lệ. Trường hợp đối xứng áp dụng cho việc cập nhật PHY do thiết bị cục bộ khởi tạo theo sau bởi LL_REJECT_IND.
Trong cấu hình mặc định (CONFIG_BT_ASSERT và CONFIG_BT_CTLR_ASSERT_DEBUG đều có giá trị mặc định là y), bất biến vi phạm trong llcp_lr_check_done()/llcp_rr_check_done() kích hoạt một assertion của controller, kết thúc bằng k_oops()(hoặc k_panic()) — chỉ cần một chuỗi PDU được tạo ra từ vùng phủ sóng radio cũng khiến thiết bị gặp sự cố. Khi các assertions này được biên dịch loại bỏ (compiled out), mỗi nỗ lực sẽ rò rỉ im lặng một nút PDU nhận và liên kết memq của nó; vì pool nhận của controller khá nhỏ (PDU_RX_CNT, phụ thuộc vào CONFIG_BT_CTLR_RX_BUFFERS, mặc định là 1) và chi phí cho kẻ tấn công chỉ là việc kết nối lại, vài lần lặp sẽ làm cạn kiệt pool này và khiến Bluetooth không hoạt động được cho đến khi khởi động lại. Trên các bản phát hành v3.4.0 đến v3.7.x, assertion chưa bao giờ đạt tới bất kể cấu hình nào, do đó mọi nỗ lực đều rò rỉ im lặng.
Tác động bị giới hạn ở tính sẵn sàng: nút cô lập không để lại con trỏ treo (dangling pointer) sau này được giải tham chiếu và cũng không bao giờ được chuyển đến host, nên không có lỗi hỏng bộ nhớ hay tiết lộ thông tin. Cùng pull request đó áp dụng bản sửa tương tự cho các thủ tục Cập nhật Kết nối và Tạo CIS, nơi các nhánh PDU không hợp lệ của chúng cũng mắc phải sự bỏ sót tương tự.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.