GHSA-VFRJ-34F5-PWH8
Vulnerability from github – Published: 2026-09-24 18:31 – Updated: 2026-09-24 18:31In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: hci_core: use skb_get() instead of skb_clone() for req_skb
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 hci_req_cmd_complete() BT_DBG), but the waiter in __hci_cmd_sync_sk() never woke up and timed out after 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 not set, hci_cmd_sync_complete() never called, req_status stays HCI_REQ_PEND --> <-- 10 s later: wait_event_interruptible_timeout expires --> bluetooth hci0: end: err -110 // __hci_cmd_sync_sk
The root cause is that hci_send_cmd_sync() clones the sent command into hdev->req_skb so that hci_req_cmd_complete() can locate the registered completion callback. Under memory pressure this skb_clone() fails, leaving hdev->req_skb NULL. The firmware reply is received and processed, but hci_req_cmd_complete() finds NULL req_skb, so hci_cmd_sync_complete() is never called, req_status stays HCI_REQ_PEND, and the waiter times out with -ETIMEDOUT.
req_skb is only used to read bt_cb(skb)->hci callbacks and opcode -- it is never modified. Replace skb_clone() with skb_get(), which simply increments the reference count of hdev->sent_cmd without allocating new memory and therefore cannot fail.
This issue was first observed as a use-after-free in ttyport_close() when ttyport_open() 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-quic_cxin@quicinc.com/
{
"affected": [],
"aliases": [
"CVE-2026-93209"
],
"database_specific": {
"cwe_ids": [],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-09-24T16:17:15Z",
"severity": null
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: hci_core: use skb_get() instead of skb_clone() for req_skb\n\nBT enable fails intermittently with -ETIMEDOUT (-110). The kernel log\nshows the HCI Read Local Version command was sent and the firmware\nreplied with status 0x00 (logged by hci_req_cmd_complete() BT_DBG),\nbut the waiter in __hci_cmd_sync_sk() never woke up and timed out\nafter 10 s:\n\n bluetooth hci0: Opcode 0xfc00 // __hci_cmd_sync_sk\n bluetooth hci0: opcode 0xfc00 plen 1 // hci_cmd_sync_add\n bluetooth hci0: skb len 4 // hci_cmd_sync_alloc\n bluetooth hci0: length 1 // hci_req_sync_run\n Bluetooth: hci0 cmd_cnt 1 cmd queued 1 // hci_cmd_work\n Bluetooth: hci0 type 1 len 4 // hci_send_frame\n Bluetooth: opcode 0xfc00 status 0x00 // hci_req_cmd_complete\n \u003c-- req_skb NULL: req_complete_skb not set,\n hci_cmd_sync_complete() never called,\n req_status stays HCI_REQ_PEND --\u003e\n \u003c-- 10 s later: wait_event_interruptible_timeout expires --\u003e\n bluetooth hci0: end: err -110 // __hci_cmd_sync_sk\n\nThe root cause is that hci_send_cmd_sync() clones the sent command\ninto hdev-\u003ereq_skb so that hci_req_cmd_complete() can locate the\nregistered completion callback. Under memory pressure this\nskb_clone() fails, leaving hdev-\u003ereq_skb NULL. The firmware reply\nis received and processed, but hci_req_cmd_complete() finds NULL\nreq_skb, so hci_cmd_sync_complete() is never called, req_status\nstays HCI_REQ_PEND, and the waiter times out with -ETIMEDOUT.\n\nreq_skb is only used to read bt_cb(skb)-\u003ehci callbacks and opcode --\nit is never modified. Replace skb_clone() with skb_get(), which\nsimply increments the reference count of hdev-\u003esent_cmd without\nallocating new memory and therefore cannot fail.\n\nThis issue was first observed as a use-after-free in ttyport_close()\nwhen ttyport_open() failed, which was investigated in an earlier\npatch series [1]. That investigation led to the discovery of the\ntrue root cause described above.\n\n[1] https://lore.kernel.org/all/20250430111617.1151390-1-quic_cxin@quicinc.com/",
"id": "GHSA-vfrj-34f5-pwh8",
"modified": "2026-09-24T18:31:22Z",
"published": "2026-09-24T18:31:22Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-93209"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0337fb092873a4146aa854acb554675b49c8f6b5"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/26f66d5b8a5663af498f7ccc94fc79fb47a2191f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d0b28e9655f4b3195210627577f81883dc1d0162"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d5eef0747071934a1c080ee617fa4fd3566394c5"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d7723320db4c9cb9ec2b9a36140e6c641dd77814"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f5afdff569a09d1cb8cf19826199d024725576cb"
}
],
"schema_version": "1.4.0",
"severity": []
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.