CVE-2026-46275CWE-362

CVE-2026-46275

High · published June 8, 2026

CVSS v3.1
7.8
EPSS
0%
Percentile
8.1
In the wild
Unconfirmed
What it is

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.

The record
Technical detail
CVSS v3.1
7.8 · HIGH
Vector
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS v4.0
Not supplied
EPSS
0.00189 · 8.1th percentile
Weakness
CWE-362 · Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition')
Published
2026-06-08T20:16Z
Affected products (15)
ProductVersionsFixed in
linux/linux_kernel≥ 4.14.203, < 4.154.15
linux/linux_kernel≥ 4.19.153, < 4.204.20
linux/linux_kernel≥ 5.4.73, < 5.55.5
linux/linux_kernel≥ 5.8.17, < 5.95.9
linux/linux_kernel≥ 5.9.2, < 5.10.2585.10.258
linux/linux_kernel≥ 5.11, < 5.15.2095.15.209
linux/linux_kernel≥ 5.16, < 6.1.1756.1.175
linux/linux_kernel≥ 6.2, < 6.6.1426.6.142
linux/linux_kernel≥ 6.7, < 6.12.926.12.92
linux/linux_kernel≥ 6.13, < 6.18.346.18.34
linux/linux_kernel≥ 6.19, < 7.0.117.0.11
linux/linux_kernelall versions—
linux/linux_kernelall versions—
linux/linux_kernelall versions—
linux/linux_kernelall versions—
References (9)
EPSS history
Timeline
  • 08 JUN 14:30Z
    Bluetooth: hci_uart: fix UAFs and race conditions in close and init paths
    cvelistv5