CVE-2026-46275: Linux Kernel Use-After-Free Vulnerability

CVE-2026-46275 Overview

CVE-2026-46275 is a Linux kernel vulnerability in the Bluetooth hci_uart driver. The flaw consists of multiple Use-After-Free (UAF) conditions, Null Pointer Dereferences (NPD), and data races in the close and initialization paths of the driver lifecycle. The issues stem from improper synchronization between teardown logic, workqueue scheduling, and protocol initialization state. Local attackers with the ability to interact with the Bluetooth UART interface can trigger memory corruption by racing TTY hangup events with setup completion. The vulnerability has been resolved upstream through multiple commits that re-order teardown operations and tighten lock acquisition.

Critical Impact

Triggering the race conditions can lead to kernel memory corruption, potential local privilege escalation, or a denial of service through kernel panic.

Affected Products

• Linux kernel versions containing the hci_uart Bluetooth driver prior to the fix commits
• Distributions shipping vulnerable stable kernel branches
• Systems using UART-attached Bluetooth controllers

Discovery Timeline

• 2026-06-08 - CVE-2026-46275 published to NVD
• 2026-06-08 - Last updated in NVD database

Technical Details for CVE-2026-46275

Vulnerability Analysis

The vulnerability affects drivers/bluetooth/hci_ldisc.c and related hci_uart code paths. The driver manages Bluetooth HCI traffic over UART using TTY line discipline and tracks readiness through the HCI_UART_PROTO_READY flag. The workqueues init_ready and write_work are only flushed when this flag is set during TTY close.

When a TTY hangup occurs before setup completes, hci_uart_tty_close() skips teardown of these workqueues and frees the hu struct. Scheduled work executing later dereferences freed memory, producing a UAF condition.

Root Cause

The root cause is incorrect lifecycle ordering across multiple paths. First, hci_uart_flush() is called from hci_uart_close() without disabling write_work, allowing concurrent invocations of hci_uart_tx_wakeup() to double-free hu->tx_skb. Second, hci_free_dev(hdev) runs before hu->proto->close(hu), which causes vendor protocol callbacks to dereference a freed hu->hdev. Third, initialization error paths clear PROTO_READY without taking the proto_lock write lock, racing with active readers. Finally, hci_uart_tty_receive() accesses hu->hdev outside the read lock.

Attack Vector

An attacker with local access and the ability to control or trigger TTY operations on the Bluetooth UART interface can induce the race. By forcing a hangup before protocol setup completes, or by inducing rapid open/close cycles, the attacker triggers concurrent execution between teardown logic and scheduled work or protocol timers. The resulting memory corruption can be leveraged toward kernel privilege escalation or used to crash the system. The vulnerability is not network exploitable and requires local interaction with the driver.

The upstream fix re-orders hci_uart_tty_close() to clear HCI_UART_PROTO_READY first, immediately followed by cancel_work_sync(&hu->write_work). It relocates hu->proto->close(hu) before hci_free_dev(hdev) in all paths, moves the hdev->stat.byte_rx increment inside the proto_lock read-side critical section, and uses cancel_work_sync() rather than disable_work_sync() to preserve user-space retry semantics. See the Kernel Git Commit 192cb0f1 and Kernel Git Commit 78aad93e for the patch contents.

Detection Methods for CVE-2026-46275

Indicators of Compromise

• Kernel oops or panic messages referencing hci_uart_write_work, hci_uart_tty_receive, or hci_uart_tx_wakeup in dmesg or /var/log/kern.log
• KASAN reports identifying use-after-free or double-free conditions in the hci_uart module
• Unexpected Bluetooth subsystem crashes correlated with TTY open or hangup activity

Detection Strategies

• Audit running kernel versions against the fixed commits referenced in the kernel.org stable tree
• Enable KASAN on test or canary systems to surface UAF and double-free conditions in the Bluetooth stack
• Monitor for unprivileged processes performing repeated open, ioctl, and close operations on /dev/tty* devices bound to Bluetooth line discipline

Monitoring Recommendations

• Collect kernel crash dumps and forward them to a centralized log store for inspection
• Alert on repeated Bluetooth subsystem restarts or hci device re-registration events
• Track Linux kernel package versions across the fleet and flag hosts running pre-patch kernels with active Bluetooth hardware

How to Mitigate CVE-2026-46275

Immediate Actions Required

• Apply the latest stable kernel updates from your distribution that include the upstream hci_uart fixes
• Identify systems exposing UART-attached Bluetooth controllers and prioritize patching
• Restrict local user access on multi-user systems pending patch deployment

Patch Information

The vulnerability is resolved by a series of upstream commits in the Linux stable tree. Reference the following patches: Kernel Git Commit 192cb0f1, Kernel Git Commit 73380319, Kernel Git Commit 78aad93e, Kernel Git Commit 81c7a3c2, Kernel Git Commit 9d20d48b, Kernel Git Commit c1bb9336, Kernel Git Commit c85cff64, and Kernel Git Commit e2d19969. Install distribution kernels that incorporate these commits and reboot affected hosts.

Workarounds

• Blacklist the hci_uart kernel module on systems that do not require UART-attached Bluetooth functionality
• Disable Bluetooth services such as bluetooth.service on servers and headless systems where Bluetooth is unused
• Limit access to TTY devices associated with Bluetooth controllers using device permissions and udev rules

# Blacklist the hci_uart module and disable Bluetooth services
echo "blacklist hci_uart" | sudo tee /etc/modprobe.d/blacklist-hci_uart.conf
sudo systemctl disable --now bluetooth.service
sudo update-initramfs -u