CVE-2026-93209: Bluetooth: hci_core: use skb_get() instead of skb_clone() for req_skb

In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: hcicore: use skbget() instead of skbclone() for reqskb

BT enable fails intermittently with -ETIMEDOUT (-110). The kernel log shows the HCI Read Local Version command was sent and the firmware replied with status 0x00 (logged by hcireqcmdcomplete() BTDBG), but the waiter in hcicmdsyncsk() never woke up and timed out after 10 s:

bluetooth hci0: Opcode 0xfc00 // hcicmdsyncsk bluetooth hci0: opcode 0xfc00 plen 1 // hcicmdsyncadd bluetooth hci0: skb len 4 // hcicmdsyncalloc bluetooth hci0: length 1 // hcireqsyncrun Bluetooth: hci0 cmdcnt 1 cmd queued 1 // hcicmdwork Bluetooth: hci0 type 1 len 4 // hcisendframe Bluetooth: opcode 0xfc00 status 0x00 // hcireqcmdcomplete <-- reqskb NULL: reqcompleteskb not set, hcicmdsynccomplete() never called, reqstatus stays HCIREQPEND --> <-- 10 s later: waiteventinterruptibletimeout expires --> bluetooth hci0: end: err -110 // hcicmdsyncsk

The root cause is that hcisendcmdsync() clones the sent command into hdev->reqskb so that hcireqcmdcomplete() can locate the registered completion callback. Under memory pressure this skbclone() fails, leaving hdev->reqskb NULL. The firmware reply is received and processed, but hcireqcmdcomplete() finds NULL reqskb, so hcicmdsynccomplete() is never called, reqstatus stays HCIREQPEND, and the waiter times out with -ETIMEDOUT.

reqskb is only used to read btcb(skb)->hci callbacks and opcode -- it is never modified. Replace skbclone() with skbget(), which simply increments the reference count of hdev->sentcmd without allocating new memory and therefore cannot fail.

This issue was first observed as a use-after-free in ttyportclose() when ttyportopen() failed, which was investigated in an earlier patch series [1]. That investigation led to the discovery of the true root cause described above.

[1] https://lore.kernel.org/all/20250430111617.1151390-1-quiccxin@quicinc.com/