CVE-2026-93209 - Vulnerability Details

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

Description

In 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/

Published: 2026-09-24

Score: n/a

EPSS: < 1% Very Low

KEV: No

Impact:

Action:

Analysis

Impact

The problem is a kernel bug in the Bluetooth core (hci_core) where the function hci_send_cmd_sync() clones a command skb into hdev->req_skb with skb_clone(). Under memory pressure that clone can fail, leaving hdev->req_skb NULL. The Bluetooth firmware later replies, but the completion routine hci_req_cmd_complete() cannot find the request skb and therefore never calls hci_cmd_sync_complete(). The original sync function __hci_cmd_sync_sk() waits for the completion and eventually times out after ten seconds, returning the error ETIMEDOUT (-110). This results in Bluetooth devices failing to enable, causing an intermittent denial‑of‑service for any application that relies on Bluetooth stacks. The weakness does not allow code execution or data disclosure, but it does prevent reliable operation of Bluetooth functionality.

Affected Systems

All Linux kernel installations that have not yet incorporated the skb_get patch are affected. The regression resides in the default Bluetooth stack bundled with the kernel, so any distribution that ships a stock kernel prior to the commit that replaces skb_clone() with skb_get() is vulnerable. This includes mainstream distributions such as Red Hat Enterprise Linux, CentOS, Debian, Ubuntu, Fedora, SUSE, and any other vendor that has not backported the fix. Embedded devices and custom kernel builds that use the upstream Open Source kernel will also be impacted as long as the patch is missing.

Risk and Exploitability

The available metrics show an EPSS score is not available and the vulnerability is not listed in the CISA KEV catalog, indicating no known widespread exploitation. The bug requires kernel execution or the ability to force a memory allocation failure to trigger the issue, limiting practical exploitation to users with local privileged access. Because the vulnerability simply causes a timeout and not arbitrary code execution, the risk is moderate and primarily pertains to service availability and user experience. No remote exploitation vector has been documented, and the issue is classified as a local denial‑of‑service scenario.

Default status is the baseline for the product, each version can override it (e.g. patched versions marked unaffected).

Vendor Product Default status Versions

Linux

unaffected

Version	Status	Constraints
`da77c1d39bc527b31890bfa0405763c82828defb`	affected	< 0337fb092873a4146aa854acb554675b49c8f6b5
`2af7aa6685e22d0dc546b0d27e5f16d3afe211fa`	affected	< d5eef0747071934a1c080ee617fa4fd3566394c5
`2615fd9a7c2507eb3be3fbe49dcec88a2f56454a`	affected	< d7723320db4c9cb9ec2b9a36140e6c641dd77814
`2615fd9a7c2507eb3be3fbe49dcec88a2f56454a`	affected	< d0b28e9655f4b3195210627577f81883dc1d0162
`2615fd9a7c2507eb3be3fbe49dcec88a2f56454a`	affected	< 26f66d5b8a5663af498f7ccc94fc79fb47a2191f
`2615fd9a7c2507eb3be3fbe49dcec88a2f56454a`	affected	< f5afdff569a09d1cb8cf19826199d024725576cb
`4ff121be63b761950610f422437aaaef8e075c40`	affected	—
`18a4c59af609994552c8b39c5438304e070e55c7`	affected	—
`6.1.83`	affected	< 6.1.118
`6.6.23`	affected	< 6.6.157
`6.7.11`	affected	< 6.8
`6.8.2`	affected	< 6.9

Linux

affected

Version	Status	Constraints
`6.9`	affected	—
`0`	unaffected	< 6.9
`6.1.118`	unaffected	≤ 6.1.*
`6.6.157`	unaffected	≤ 6.6.*
`6.12.109`	unaffected	≤ 6.12.*
`6.18.50`	unaffected	≤ 6.18.*
`7.2.4`	unaffected	≤ 7.2.*
`7.3-rc1`	unaffected	≤ *

No data.

Vendor Product Confidence Versions

Linux

Linux Kernel

99%

Version	Status	Scheme	Platform
`[da77c1d39bc527b31890bfa0405763c82828defb,0337fb092873a4146aa854acb554675b49c8f6b5)`	affected	code_commit	—
`[2af7aa6685e22d0dc546b0d27e5f16d3afe211fa,d5eef0747071934a1c080ee617fa4fd3566394c5)`	affected	code_commit	—
`[2615fd9a7c2507eb3be3fbe49dcec88a2f56454a,d7723320db4c9cb9ec2b9a36140e6c641dd77814)`	affected	code_commit	—
`[2615fd9a7c2507eb3be3fbe49dcec88a2f56454a,d0b28e9655f4b3195210627577f81883dc1d0162)`	affected	code_commit	—
`[2615fd9a7c2507eb3be3fbe49dcec88a2f56454a,26f66d5b8a5663af498f7ccc94fc79fb47a2191f)`	affected	code_commit	—
`[2615fd9a7c2507eb3be3fbe49dcec88a2f56454a,f5afdff569a09d1cb8cf19826199d024725576cb)`	affected	code_commit	—
`4ff121be63b761950610f422437aaaef8e075c40`	affected	code_commit	—
`18a4c59af609994552c8b39c5438304e070e55c7`	affected	code_commit	—
`[6.1.83,6.1.118)`	affected	semver	—
`[6.6.23,6.6.157)`	affected	semver	—
`[6.7.11,6.8)`	affected	generic	—
`[6.8.2,6.9)`	affected	generic	—

Linux

Linux Kernel

99%

Version	Status	Scheme	Platform
`6.9`	affected	generic	—
`[0,6.9)`	unaffected	generic	—
`[6.1118,6.2.0)`	unaffected	semver	—
`[6.6.157,6.7.0)`	unaffected	semver	—
`[6.12.109,6.13.0)`	unaffected	semver	—
`[6.18.50,6.19.0)`	unaffected	semver	—
`[7.2.4,7.3.0)`	unaffected	semver	—
`[7.3-rc1,*]`	unaffected	generic	—

Found an issue or want to improve our Enrichment? You can suggest it directly by opening an issue on our dedicated GitHub repository .

Remediation

No solution or workaround provided in the CVE record.

OpenCVE Recommended Actions

Update the Linux kernel to a version that contains the skb_get patch for hci_core, thereby eliminating the skb_clone allocation failure that causes the timeout.
If a kernel upgrade cannot be performed immediately, disable the Bluetooth driver or module (for example, by removing or blacklisting it) to prevent intermittent enable failures until a patched kernel is available.
After applying the update, monitor system logs for repeated ETIMEDOUT errors to verify that the issue has been fully resolved.

Generated by OpenCVE AI on September 26, 2026 at 01:09 UTC.

Tracking

Sign in to view the affected projects.

Advisories

Source	ID	Title
Debian DLA	DLA-4817-1	linux-6.12 security update
Debian DSA	DSA-6528-1	linux security update

No CVSS v4.0

No CVSS v3.1

No CVSS v3.0

No CVSS v2

This CVE is not in the KEV list.

The EPSS score is 0.00172.

Key SSVC decision points have not yet been added.

References

Link	Providers
https://git.kernel.org/stable/c/0337fb092873a4146aa854acb554675b49c8f6b5
https://git.kernel.org/stable/c/26f66d5b8a5663af498f7ccc94fc79fb47a2191f
https://git.kernel.org/stable/c/d0b28e9655f4b3195210627577f81883dc1d0162
https://git.kernel.org/stable/c/d5eef0747071934a1c080ee617fa4fd3566394c5
https://git.kernel.org/stable/c/d7723320db4c9cb9ec2b9a36140e6c641dd77814
https://git.kernel.org/stable/c/f5afdff569a09d1cb8cf19826199d024725576cb

History

Sat, 26 Sep 2026 01:30:00 +0000

Type	Values Removed	Values Added
Weaknesses		CWE-399 CWE-416

Thu, 24 Sep 2026 15:30:00 +0000

Type	Values Removed	Values Added
Description		In 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/
Title		Bluetooth: hci_core: use skb_get() instead of skb_clone() for req_skb
First Time appeared		Linux Linux linux Kernel
CPEs		cpe:2.3:o:linux:linux_kernel::::::::
Vendors & Products		Linux Linux linux Kernel
References		https://git.kernel.org/stable/c/0337fb092873a4146aa854acb554675b49c8f6b5 https://git.kernel.org/stable/c/26f66d5b8a5663af498f7ccc94fc79fb47a2191f https://git.kernel.org/stable/c/d0b28e9655f4b3195210627577f81883dc1d0162 https://git.kernel.org/stable/c/d5eef0747071934a1c080ee617fa4fd3566394c5 https://git.kernel.org/stable/c/d7723320db4c9cb9ec2b9a36140e6c641dd77814 https://git.kernel.org/stable/c/f5afdff569a09d1cb8cf19826199d024725576cb

Subscriptions

Linux Linux Kernel

MITRE

Status: PUBLISHED

Assigner: Linux

Published: 2026-09-24T15:10:32.762Z

Updated: 2026-09-24T15:10:32.762Z

Reserved: 2026-09-17T16:02:15.093Z

Link: CVE-2026-93209

Vulnrichment

No data.

NVD

Status : Received

Published: 2026-09-24T16:17:15.710

Modified: 2026-09-24T16:17:15.710

Link: CVE-2026-93209

Redhat

No data.

OpenCVE Enrichment

Updated: 2026-09-26T01:15:08Z

Weaknesses

CWE-399
CWE-416
Use After Free

Impact

Affected Systems

Risk and Exploitability

Tracking

Subscriptions

JSON object

JSON object

JSON object

JSON object

JSON object