Skip to main content

Linux Kernel CVE-2026-68085

| EUVDEUVD-2026-55266 HIGH
2026-08-10 Linux GHSA-mhcf-ghw6-c6wv
Information Disclosure Linux
High
Disputed · 8.0 Vendor: Linux
Share

Severity by source

Sources disagree (Low–High)
Vendor (Linux) PRIMARY
8.0 HIGH
AV:A/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
vuln.today AI
7.1 HIGH

Race condition timing makes AC:H warranted; AV:A and PR:L reflect UART BT driver access requirements; C:H/I:H retained for potential UAF from unsafe tx_skb clearing.

3.1 AV:A/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
4.0 AV:A/AC:H/AT:P/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N
SUSE
2.3 LOW
AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:L
Red Hat
5.5 MEDIUM
qualitative

vuln.today treats the vendor’s rating as authoritative. A higher third-party CVSS (e.g. CISA-ADP) is shown for transparency but does not drive the headline severity.

CVSS VectorVendor: Linux

Attack Vector
Adjacent
Attack Complexity
Low
Privileges Required
Low
User Interaction
None
Scope
Unchanged
Confidentiality
High
Integrity
High
Availability
High

Lifecycle Timeline

5
Analysis Generated
Aug 14, 2026 - 02:10 vuln.today
CVSS changed
Aug 13, 2026 - 23:37 NVD
8.0 (HIGH)
Patch available
Aug 10, 2026 - 13:03 EUVD
CVE Published
Aug 10, 2026 - 11:51 cve.org
HIGH 8.0
CVE Published
Aug 10, 2026 - 11:51 cve.org
UNKNOWN (no severity yet)

DescriptionCVE.org

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

Bluetooth: hci_uart: clear HCI_UART_SENDING when write_work is canceled

HCI_UART_SENDING bit in tx_state means write_work is pending and blocks queueing it again. Currently this bit is not cleared when canceling the work in hci_uart_close(), which blocks future writes when device is reopened later if write_work was pending.

Fix by clearing HCI_UART_SENDING when canceling the work.

Also make clearing of tx_skb safe by using disable_work_sync + enable_work instead of just cancel_work_sync. hci_uart_flush() purges the proto tx queue so we can cancel the pending write_work there, instead of doing it just in hci_uart_close(). Re-enable and possibly requeue the work after queue flush.

AnalysisAI

Race condition and state management bug in the Linux kernel Bluetooth HCI UART driver (hci_uart) allows an adjacent attacker with low privileges to block all future writes to a Bluetooth UART device after it is closed and reopened, with potential for kernel memory corruption via an unsafely cleared tx_skb pointer. Affected versions span multiple stable branches from 5.10.x through 6.18.x. No public exploit has been identified at time of analysis and EPSS is very low (0.17%), though the CVSS score of 8.0 with high C/I/A impact signals potential for use-after-free conditions beyond pure denial of service.

Technical ContextAI

The vulnerability resides in drivers/bluetooth/hci_uart.c within the Linux kernel Bluetooth HCI UART subsystem, which manages UART-attached Bluetooth chipsets (common on embedded Linux platforms, Raspberry Pi, and laptops using UART-bridged Bluetooth controllers). The root cause is a missing state clear: the HCI_UART_SENDING bit in tx_state signals that write_work is pending and prevents the work from being re-queued. When hci_uart_close() cancels write_work via cancel_work_sync(), it does not clear this bit, so after the device is closed and reopened, any future attempt to queue write_work is silently blocked. Additionally, the original code used cancel_work_sync to clear tx_skb, which is not safe under concurrent access - the fix replaces this with disable_work_sync plus enable_work to safely gate access during the flush. The CWE is not formally assigned, but this is a combination of CWE-362 (race condition on shared resource) and CWE-459 (incomplete cleanup). Affected CPE: cpe:2.3:a:linux:linux across multiple stable branches.

RemediationAI

The primary fix is to upgrade to a patched Linux kernel stable release: 6.12.96 or later for the 6.12 branch, and 6.18.39 or later for the 6.18 branch, as confirmed by EUVD patch version data. Upstream commits are available at https://git.kernel.org/stable/c/d52446b3e735cfdbdc2a58342163803bc2e64249 (one stable branch), https://git.kernel.org/stable/c/b9dd39cf1667e378b25a082ca796d495d578c5d3, https://git.kernel.org/stable/c/714d861d35d937f23375a4517569b13917bbbe51, and https://git.kernel.org/stable/c/1b0d946d6f08bd39211385bc703a440911b41e46 for the remaining affected stable branches. For systems that cannot be patched immediately, a compensating control is to disable the HCI UART Bluetooth driver module (rmmod hci_uart or blacklist it via /etc/modprobe.d/) on systems where UART-attached Bluetooth is not operationally required - this eliminates the attack surface entirely with the trade-off of losing Bluetooth UART functionality. Restricting physical and adjacent-network access to vulnerable systems reduces exposure given the AV:A vector. Distribution-specific backported patches (Debian, Ubuntu, RHEL, etc.) should be monitored independently as they may predate full upstream stable releases.

Same technique Information Disclosure

View all
CVE-2019-2725 CRITICAL POC
9.8
CVE-2021-34523 CRITICAL POC
9.0
CVE-2013-2251 CRITICAL POC
9.8
CVE-2017-5638 CRITICAL POC
9.8
CVE-2025-24813 CRITICAL POC
9.8
CVE-2015-1701 HIGH POC
7.8
CVE-2017-0147 HIGH POC
7.5
CVE-2014-6324 HIGH POC
8.8

Vendor StatusVendor

SUSE

Severity: Low
Product Status
SUSE Linux Enterprise Desktop 15 SP7 Affected
SUSE Linux Enterprise Desktop 15 SP7 Affected
SUSE Linux Enterprise High Availability Extension 15 SP7 Affected
SUSE Linux Enterprise High Availability Extension 15 SP7 Affected
SUSE Linux Enterprise High Availability Extension 16.0 Affected

Share

CVE-2026-68085 vulnerability details – vuln.today
Back

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy