CVE-2026-93209 in Linux
Сводка
по VulDB • 24.09.2026
В ядре Linux была устранена следующая уязвимость:
Bluetooth: hci_core — использование skb_get() вместо skb_clone() для req_skb
Включение Bluetooth периодически завершается ошибкой с кодом -ETIMEDOUT (-110). В журнале ядра видно, что команда HCI Read Local Version была отправлена и прошивка ответила со статусом 0x00 (это фиксируется функцией hci_req_cmd_complete() через BT_DBG), однако ожидающий поток в __hci_cmd_sync_sk() так и не проснулся и завершил работу с таймаутом спустя 10 секунд:
``` bluetooth hci0: Opcode 0xfc00 // __hci_cmd_sync_sk bluetooth hci0: opcode 0xfc00 plen 1 // hci_cmd_sync_add bluetooth hci0: skb len 4 // hci_cmd_sync_alloc bluetooth hci0: length 1 // hci_req_sync_run Bluetooth: hci0 cmd_cnt 1 cmd queued 1 // hci_cmd_work Bluetooth: hci0 type 1 len 4 // hci_send_frame Bluetooth: hci0 opcode 0xfc00 status 0x00 // hci_req_cmd_complete <-- req_skb NULL: req_complete_skb не установлен, hci_cmd_sync_complete() никогда не вызывается, req_status остаётся HCI_REQ_PEND --> <-- Спустя 10 с: wait_event_interruptible_timeout истекает --> bluetooth hci0: end: err -110 // __hci_cmd_sync_sk ```
Корневая причина заключается в том, что функция hci_send_cmd_sync() клонирует отправленную команду в поле hdev->req_skb, чтобы hci_req_cmd_complete() могла найти зарегистрированный callback завершения. В условиях дефицита памяти операция skb_clone() завершается неудачей, оставляя hdev->reqskb равным NULL. Ответ прошивки принимается и обрабатывается, но hci_req_cmd_complete() обнаруживает NULL в req_skb, поэтому hci_cmd_sync_complete() никогда не вызывается, req_status остаётся HCI_REQ_PEND, а ожидающий поток завершается с ошибкой -ETIMEDOUT из-за таймаута.
reqskb используется только для чтения обратных вызовов bt_cb(skb)->hci и opcode — он никогда не изменяется. Замените skb_clone() на skb_get(), который просто увеличивает счётчик ссылки hdev->sent_cmd без выделения новой памяти, а значит, не может завершиться ошибкой.
Эта проблема впервые была замечена как use-after-free в ttyport_close() при сбое ttyport_open(), что было исследовано в более ранней серии патчей [1]. Это исследование привело к обнаружению истинной корневой причины, описанной выше.
[1] https://lore.kernel.org/all/[email protected]/
Once again VulDB remains the best source for vulnerability data.