CVE-2026-90087 in Linux
Tóm tắt
Bởi VulDB • 18/09/2026
Trong kernel Linux, lỗ hổng sau đây đã được khắc phục:
Bluetooth: không làm rò rỉ đối tượng hci_conn khi kết nối LE thứ hai bị từ chối
Hàm `create_le_conn_complete()` quyết định xem kết nối thất bại có còn đang chờ xử lý hay không bằng cách so sánh nó với `hci_lookup_le_connect()`, hàm này trả về kết nối LE đầu tiên trong trạng thái BT_CONNECT. Điều này chỉ đúng khi tối đa một kết nối đang được chờ xử lý.
Có thể có hai kết nối cùng lúc ở trạng thái chờ (pending). Các kết nối được tạo trên đường dẫn quét thụ động (passive scan path) nằm trong trạng thái BT_CONNECT với cờ HCI_CONN_SCANNING được đặt, và sẽ không hiển thị đối với `hci_lookup_le_connect()` cho đến khi `hci_le_create_conn_sync()` xóa cờ này sau khi lệnh của chúng được gửi đi. Do đó, bộ bảo vệ -EBUSY trong `hci_connect_le()` không ngăn chặn việc một kết nối thứ hai được xếp hàng chờ xử lý trong khi kết nối đầu tiên vẫn đang ở đường dẫn quét. Khi có hai kết nối cùng lúc ở trạng thái BT_CONNECT, hàm tra cứu (`lookup`) có thể trả về một kết nối trong khi `create_le_conn_complete()` báo cáo lỗi của kết nối kia; việc thoát sớm (early exit) sau đó sẽ làm mất thông tin lỗi và `hci_conn_failed()` không bao giờ được chạy cho kết nối bị thất bại.
Bộ điều khiển cũng từ chối lệnh HCI_OP_LE_CREATE_CONN thứ hai nếu đang có một yêu cầu tạo kết nối khác vẫn còn dang dở, theo Quy chuẩn Cốt lõi (Core Spec) Tập 4, Phần E. Quy chuẩn này yêu cầu trả về lỗi "Command Disallowed" ở trường hợp đó; tuy nhiên, thiết bị bcm43438 quan sát được trong tình huống này đã phản hồi bằng mã lỗi LMP/LL thay thế, mà hàm `bt_to_errno()` ánh xạ thành -EPROTO (-71) như hiển thị trong nhật ký bên dưới.
Kết nối bị rò rỉ sẽ ở trạng thái BT_CONNECT mãi mãi, và vì `hci_connect_le()` từ chối thực hiện kết nối khi `hci_lookup_le_connect()` tìm thấy bất kỳ đối tượng nào, mọi nỗ lực kết nối tiếp theo với bất kỳ thiết bị đầu cuối (peer) nào đều thất bại với lỗi -EBUSY và không có lệnh nào được gửi đến bộ điều khiển.
Tình huống này đã quan sát được trên một thiết bị bcm43438 với hai peer BLE được thăm dò ở cùng khoảng thời gian (trạng thái 5 là BT_CONNECT; cả hai handle đều là các giá trị UNSET, được phân bổ từ ida phía trên HCI_CONN_HANDLE_MAX):
Bluetooth: hci1: Opcode 0x2013 failed: -71
# hcitool con < LE 14:9C:EF:03:68:81 handle 3840 state 5 lm CENTRAL < LE C4:D3:6A:8C:B5:38 handle 3841 state 5 lm CENTRAL
Một bản ghi btmon trong mười phút tiếp theo của các nỗ lực kết nối không chứa bất kỳ lệnh HCI_OP_LE_CREATE_CONN nào; các kết nối LE đi ra không thể phục hồi cho đến khi bộ điều hợp (adapter) được đặt lại. Với thay đổi này, cùng một tình huống sẽ xử lý sạch sẽ việc từ chối kết nối và các lần kết nối tiếp theo với cả hai peer đều thành công.
Hãy hỏi về chính kết nối đó thay vì hỏi về thiết bị.
If you want to get best quality of vulnerability data, you may have to visit VulDB.