CVE-2026-93209 in Linux
Resumen
por VulDB • 2026-09-24
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad:
Bluetooth: hci_core: usar skb_get() en lugar de skb_clone() para req_skb
La habilitación de Bluetooth falla intermitentemente con -ETIMEDOUT (-110). El registro del kernel muestra que se envió el comando HCI Read Local Version y el firmware respondió con estado 0x00 (registrado por hci_req_cmd_complete() BT_DBG), pero el proceso en espera en __hci_cmd_sync_sk() nunca despertó y agotó el tiempo de espera después de 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 no establecido, hci_cmd_sync_complete() nunca llamada, req_status permanece HCI_REQ_PEND --> <-- 10 s después: wait_event_interruptible_timeout expira --> bluetooth hci0: end: err -110 // __hci_cmd_sync_sk
La causa raíz es que hci_send_cmd_sync() clona el comando enviado en hdev->req_skb para que hci_req_cmd_complete() pueda localizar la devolución de llamada (callback) registrada. Bajo presión de memoria, skb_clone() falla, dejando hdev->req_skb como NULL. La respuesta del firmware se recibe y procesa, pero hci_req_cmd_complete() encuentra req_skb NULL, por lo que hci_cmd_sync_complete() nunca se llama, req_status permanece en HCI_REQ_PEND y el proceso en espera agota el tiempo de espera con -ETIMEDOUT.
req_skb solo se utiliza para leer las devoluciones de llamada bt_cb(skb)->hci y opcode; no se modifica nunca. Se reemplaza skb_clone() por skb_get(), que simplemente incrementa la cuenta de referencias de hdev->sent_cmd sin asignar nueva memoria, por lo tanto, no puede fallar.
Este problema se observó inicialmente como un use-after-free en ttyport_close() cuando ttyport_open() fallaba, lo cual fue investigado en una serie anterior de parches [1]. Esa investigación llevó al descubrimiento de la verdadera causa raíz descrita anteriormente.
[1] https://lore.kernel.org/all/[email protected]/
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.