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

Bluetooth: hci_uart: fix UAFs and race conditions in close and init paths

Vulnerabilities leading to Use-After-Free (UAF) and Null Pointer
Dereference (NPD) conditions were observed in the lifecycle management
of hci_uart.

The primary issue arises because the workqueues (init_ready and
write_work) are only flushed/cancelled if the HCI_UART_PROTO_READY
flag is set during TTY close. If a hangup occurs before setup completes,
hci_uart_tty_close() skips the teardown of these workqueues and
proceeds to free the `hu` struct. When the scheduled work executes
later, it blindly dereferences the freed `hu` struct.

Furthermore, several data races and UAFs were identified in the teardown
sequence:
1. Calling hci_uart_flush() from hci_uart_close() without effectively
disabling write_work causes a race condition where both can concurrently
double-free hu->tx_skb. This happens because protocol timers can
concurrently invoke hci_uart_tx_wakeup() and requeue write_work.
2. Calling hci_free_dev(hdev) before hu->proto->close(hu) causes a UAF
when vendor specific protocol close callbacks dereference hu->hdev.
3. In the initialization error paths, failing to take the proto_lock
write lock before clearing PROTO_READY leads to races with active
readers. Additionally, hci_uart_tty_receive() accesses hu->hdev
outside the read lock, leading to UAFs if the initialization error
path frees hdev concurrently.

Fix these synchronization and lifecycle issues by:
1. Re-ordering hci_uart_tty_close() to clear HCI_UART_PROTO_READY first,
followed immediately by a cancel_work_sync(&hu->write_work). Clearing
the flag locks out concurrent protocol timers from successfully invoking
hci_uart_tx_wakeup(), effectively rendering the cancellation permanent
and preventing the tx_skb double-free.
2. Note: Clearing PROTO_READY early causes hci_uart_close() to skip
hu->proto->flush(). This is perfectly safe in the tty_close path
because hu->proto->close() executes shortly after, which intrinsically
purges all protocol SKB queues and tears down the state.
3. Relocating hu->proto->close(hu) strictly prior to hci_free_dev(hdev)
across all close and error paths to prevent vendor-level UAFs.
4. Moving the hdev->stat.byte_rx increment in hci_uart_tty_receive()
inside the proto_lock read-side critical section to safely synchronize
with device unregistration.
5. Adding cancel_work_sync(&hu->write_work) to hci_uart_close() to safely
flush the workqueue before hci_uart_flush() is invoked via the HCI core.
6. Utilizing cancel_work_sync() instead of disable_work_sync() across
all paths to prevent permanently breaking user-space retry capabilities.
Published: 2026-06-08
Score: n/a
EPSS: n/a
KEV: No
Impact: n/a
Action: n/a
AI Analysis

Impact

The vulnerability originates from improperly flushed workqueues and missing locks in the Linux kernel Bluetooth hci_uart driver. During TTY close or initialization error paths, the driver may free the hu structure before scheduled work executes, causing use‑after‑free (UAF) and null pointer dereference (NPD) conditions. These flaws enable kernel memory corruption, which could be leveraged by an attacker with local access to the Bluetooth subsystem to execute arbitrary code or crash the system.

Affected Systems

All Linux kernel releases that ship the hci_uart driver without the patch are affected. The vendor is Linux and the product is the Linux kernel. No specific affected version range is listed in the metadata, so any kernel prior to the implementation of the cited patches is considered vulnerable.

Risk and Exploitability

EPSS is not available and the vulnerability is not listed in the CISA KEV catalog, so industry‑wide exploitation probability is unknown. The CVSS score is unspecified. The most likely attack vector is local or remote interaction with the Bluetooth stack: an attacker could initiate a malformed Bluetooth connection or exploit a driver misuse to trigger the faulty path. Because the flaw consumes kernel resources, successful exploitation could lead to privilege escalation, arbitrary code execution with kernel privileges, or denial of service. The lack of public exploits suggests the risk is moderate to high for systems that expose the Bluetooth interface to untrusted devices.

Generated by OpenCVE AI on June 8, 2026 at 16:53 UTC.

Remediation

No vendor fix or workaround currently provided.

OpenCVE Recommended Actions

  • Upgrade the Linux kernel to a release that includes the hci_uart fix (commits after 192cb0f1ca706d9a1bc36ae0ad5f666d1e4fd894).
  • If an upgrade cannot be performed immediately, disable or restrict the Bluetooth subsystem—blacklist the hci_uart module or configure Bluetooth to limit connections to known devices.
  • Ensure custom kernel configurations eliminate unnecessary Bluetooth support by removing CONFIG_BT_HCIUART support or limiting it via kernel module blacklist.

Generated by OpenCVE AI on June 8, 2026 at 16:53 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Mon, 08 Jun 2026 15:45:00 +0000

Type Values Removed Values Added
Description In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_uart: fix UAFs and race conditions in close and init paths Vulnerabilities leading to Use-After-Free (UAF) and Null Pointer Dereference (NPD) conditions were observed in the lifecycle management of hci_uart. The primary issue arises because the workqueues (init_ready and write_work) are only flushed/cancelled if the HCI_UART_PROTO_READY flag is set during TTY close. If a hangup occurs before setup completes, hci_uart_tty_close() skips the teardown of these workqueues and proceeds to free the `hu` struct. When the scheduled work executes later, it blindly dereferences the freed `hu` struct. Furthermore, several data races and UAFs were identified in the teardown sequence: 1. Calling hci_uart_flush() from hci_uart_close() without effectively disabling write_work causes a race condition where both can concurrently double-free hu->tx_skb. This happens because protocol timers can concurrently invoke hci_uart_tx_wakeup() and requeue write_work. 2. Calling hci_free_dev(hdev) before hu->proto->close(hu) causes a UAF when vendor specific protocol close callbacks dereference hu->hdev. 3. In the initialization error paths, failing to take the proto_lock write lock before clearing PROTO_READY leads to races with active readers. Additionally, hci_uart_tty_receive() accesses hu->hdev outside the read lock, leading to UAFs if the initialization error path frees hdev concurrently. Fix these synchronization and lifecycle issues by: 1. Re-ordering hci_uart_tty_close() to clear HCI_UART_PROTO_READY first, followed immediately by a cancel_work_sync(&hu->write_work). Clearing the flag locks out concurrent protocol timers from successfully invoking hci_uart_tx_wakeup(), effectively rendering the cancellation permanent and preventing the tx_skb double-free. 2. Note: Clearing PROTO_READY early causes hci_uart_close() to skip hu->proto->flush(). This is perfectly safe in the tty_close path because hu->proto->close() executes shortly after, which intrinsically purges all protocol SKB queues and tears down the state. 3. Relocating hu->proto->close(hu) strictly prior to hci_free_dev(hdev) across all close and error paths to prevent vendor-level UAFs. 4. Moving the hdev->stat.byte_rx increment in hci_uart_tty_receive() inside the proto_lock read-side critical section to safely synchronize with device unregistration. 5. Adding cancel_work_sync(&hu->write_work) to hci_uart_close() to safely flush the workqueue before hci_uart_flush() is invoked via the HCI core. 6. Utilizing cancel_work_sync() instead of disable_work_sync() across all paths to prevent permanently breaking user-space retry capabilities.
Title Bluetooth: hci_uart: fix UAFs and race conditions in close and init paths
First Time appeared Linux
Linux linux Kernel
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
References

Subscriptions

Linux Linux Kernel
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2026-06-08T14:30:54.232Z

Reserved: 2026-05-13T15:03:33.109Z

Link: CVE-2026-46275

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Received

Published: 2026-06-08T16:16:40.863

Modified: 2026-06-08T16:16:40.863

Link: CVE-2026-46275

cve-icon Redhat

No data.

cve-icon OpenCVE Enrichment

Updated: 2026-06-08T17:00:16Z

Weaknesses

No weakness.