CVE-2026-93209 in Linux
Sumário
de VulDB • 24/09/2026
No kernel do Linux, a seguinte vulnerabilidade foi resolvida:
Bluetooth: hci_core: usar skb_get() em vez de skb_clone() para req_skb
A ativação do Bluetooth falha intermitentemente com -ETIMEDOUT (-110). O log do kernel mostra que o comando HCI Read Local Version foi enviado e a firmware respondeu com status 0x00 (registrado por hci_req_cmd_complete() BT_DBG), mas o wait no __hci_cmd_sync_sk nunca acordou e expirou após 10 s:
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: opcode 0xfc00 status 0x00 // hci_req_cmd_complete <-- req_skb NULL: req_complete_skb não definido, hci_cmd_sync_complete() nunca chamada, req_status permanece HCI_REQ_PEND --> <-- Após 10 s: wait_event_interruptible_timeout expira --> bluetooth hci0: end: err -110 // __hci_cmd_sync_sk
A causa raiz é que hci_send_cmd_sync() clona o comando enviado em hdev->req_skb para que hci_req_cmd_complete() possa localizar o callback de conclusão registrado. Sob pressão de memória, este skb_clone() falha, deixando hdev->req_skb como NULL. A resposta da firmware é recebida e processada, mas hci_req_cmd_complete() encontra req_skb NULL, portanto hci_cmd_sync_complete() nunca é chamada, req_status permanece HCI_REQ_PEND e o wait expira com -ETIMEDOUT.
req_skb é usado apenas para ler os callbacks bt_cb(skb)->hci e opcode -- ele nunca é modificado. Substitua skb_clone() por skb_get(), que simplesmente incrementa a contagem de referência de hdev->sent_cmd sem alocar nova memória, portanto não pode falhar.
Este problema foi observado inicialmente como um use-after-free em ttyport_close() quando ttyport_open() falhou, o qual foi investigado em uma série anterior de patches [1]. Essa investigação levou à descoberta da verdadeira causa raiz descrita acima.
[1] https://lore.kernel.org/all/[email protected]/
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.