Skip to main content

Linux Kernel CVE-2026-46275

| EUVDEUVD-2026-35079 HIGH
Race Condition (CWE-362)
2026-06-08 Linux GHSA-mpvf-w98g-3c74
7.8
CVSS 3.1 · Vendor: Linux
Share

Severity by source

Vendor (Linux) PRIMARY
7.8 HIGH
AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
vuln.today AI
7.0 HIGH

AC:H assigned because exploitation depends on winning a kernel race condition requiring precisely timed TTY hangup; PR:L reflects required TTY device group membership.

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

Primary rating from Vendor (Linux).

CVSS VectorVendor: Linux

CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Attack Vector
Local
Attack Complexity
Low
Privileges Required
Low
User Interaction
None
Scope
Unchanged
Confidentiality
High
Integrity
High
Availability
High

Lifecycle Timeline

5
Analysis Generated
Jun 14, 2026 - 06:24 vuln.today
CVSS changed
Jun 14, 2026 - 06:22 NVD
7.8 (HIGH)
Patch available
Jun 08, 2026 - 17:01 EUVD
CVE Published
Jun 08, 2026 - 14:30 nvd
UNKNOWN (no severity yet)
CVE Published
Jun 08, 2026 - 14:30 cve.org
HIGH 7.8

DescriptionCVE.org

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.

  1. Calling hci_free_dev(hdev) before hu->proto->close(hu) causes a UAF

when vendor specific protocol close callbacks dereference hu->hdev.

  1. 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.

  1. 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.

  1. Relocating hu->proto->close(hu) strictly prior to hci_free_dev(hdev)

across all close and error paths to prevent vendor-level UAFs.

  1. 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.

  1. 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.

  1. Utilizing cancel_work_sync() instead of disable_work_sync() across

all paths to prevent permanently breaking user-space retry capabilities.

AnalysisAI

Use-After-Free and race conditions in the Linux kernel's Bluetooth hci_uart driver (drivers/bluetooth/hci_uart.c) enable a local low-privileged user to corrupt kernel heap memory, potentially escalating to root. The flaw stems from improper lifecycle management of the hci_uart struct and its associated workqueues: when a TTY hangup interrupts Bluetooth UART initialization before HCI_UART_PROTO_READY is set, teardown skips workqueue cancellation, leaving deferred work items to dereference freed memory. Three compounding sub-issues - a tx_skb double-free, a vendor callback UAF via premature hci_free_dev(), and proto_lock races during error paths - are all resolved in patched stable releases. No public exploit is known and EPSS at 0.02% (7th percentile) signals low near-term exploitation probability despite the CVSS 7.8 rating.

Technical ContextAI

The hci_uart driver bridges UART/TTY serial hardware to the Linux Bluetooth HCI stack, allocating a per-device hci_uart struct (hu) that holds pointers to the HCI device (hdev), vendor protocol callbacks (proto), deferred work items (init_ready, write_work), and a transmit socket buffer (tx_skb). The HCI_UART_PROTO_READY flag gates teardown logic in hci_uart_tty_close(). When a hangup arrives before this flag is set, close() skips cancel_work_sync() for both workqueues and frees hu - a textbook CWE-416 (Use After Free) triggered by a CWE-362 (Race Condition). Three compounding races exist: (1) concurrent hci_uart_flush() and write_work can double-free hu->tx_skb when protocol timers re-enqueue write_work; (2) hci_free_dev(hdev) executes before proto->close(hu), so vendor-specific close callbacks dereference the already-freed hdev; (3) initialization error paths clear PROTO_READY without holding proto_lock write lock, racing with hci_uart_tty_receive() which reads hu->hdev outside the read lock. The fix re-orders close and error paths to clear PROTO_READY first, adds cancel_work_sync() unconditionally, and moves proto->close() strictly before hci_free_dev(). CPE: cpe:2.3:a:linux:linux:*:*:*:*:*:*:*:*.

RemediationAI

The primary fix is upgrading to a patched stable kernel: 5.10.258, 5.15.209, 6.1.175, 6.6.142, 6.12.92, 6.18.34, or 7.0.11 (or later). Per-branch upstream commits are available at git.kernel.org stable tree references including https://git.kernel.org/stable/c/78aad93e938f013d9272fe0ee168f27883afa95c, https://git.kernel.org/stable/c/e2d19969c8d9198ecc3090bcd5312ecd503a3339, https://git.kernel.org/stable/c/c85cff648a2bc92322912db5f1727ad05afae7b6, and five additional branch-specific commits. For systems where immediate kernel patching is not feasible, the most effective compensating control is blacklisting the hci_uart module: adding 'blacklist hci_uart' to /etc/modprobe.d/bluetooth.conf and rebooting - this eliminates the attack surface entirely but disables all Bluetooth-over-serial functionality, which may impact embedded systems relying on UART Bluetooth. As a lighter-weight control, restricting read/write permissions on TTY devices (/dev/ttyS*, /dev/ttyUSB*) to a dedicated Bluetooth group via udev rules raises the privilege bar, though it does not eliminate the flaw. Systems confirmed to have no hci_uart hardware (lsmod shows module absent) are not affected and require no action.

Vendor StatusVendor

SUSE

Severity: Moderate
Product Status
openSUSE Tumbleweed Fixed
SUSE Linux Enterprise Desktop 15 SP7 Not-Affected
SUSE Linux Enterprise Desktop 15 SP7 Not-Affected
SUSE Linux Enterprise High Availability Extension 15 SP7 Not-Affected
SUSE Linux Enterprise High Availability Extension 15 SP7 Not-Affected

Share

CVE-2026-46275 vulnerability details – vuln.today

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