CVE-2026-46275

What it actually does

This is a local Linux kernel memory-safety flaw in the Bluetooth HCI UART driver lifecycle. Incorrect synchronization during TTY close, hangup, initialization failure, and protocol teardown can allow scheduled work or protocol callbacks to access freed hci_uart or hci_dev structures. The resulting use-after-free, double-free, or NULL pointer dereference can crash the kernel and, depending on allocator state and exploit reliability, may allow local privilege escalation or arbitrary kernel memory corruption. The CVSS vector indicates local access, low attack complexity, low privileges required, no user interaction, and high confidentiality, integrity, and availability impact.

Why it matters to the business

Systems using Linux kernel Bluetooth HCI UART support may be exposed to local denial of service or potential privilege escalation by a user or process with local execution. Operationally, successful exploitation could cause kernel panics, service outages, device instability, or compromise of the host with elevated privileges. Because this is not listed in CISA KEV, has no known public exploit maturity in the provided data, and has a low EPSS score, immediate internet-scale exploitation is less likely; however, kernel privilege-escalation flaws remain important to patch on multi-user systems, endpoints, embedded Linux devices, and systems where untrusted local code can run.

How an attack unfolds

An attacker first needs local code execution or the ability to interact with Bluetooth HCI UART/TTY paths on a vulnerable Linux system. They then trigger specific open, initialization, hangup, close, receive, or protocol timer sequences so that hci_uart workqueues remain scheduled while the underlying hci_uart or hci_dev object is freed, or so that teardown races with write_work and transmit wakeups. When the deferred work or protocol close path later dereferences the stale pointer, the kernel may crash or corrupt memory. A practical exploit would attempt to shape kernel heap state around the freed object and repeatedly trigger the race to convert the use-after-free into controlled memory corruption and possible privilege escalation. More commonly, unsuccessful or crude attempts would manifest as Bluetooth-related kernel oops, KASAN reports, general protection faults, or system crashes.

How to fix it

Upgrade to a Linux kernel version or vendor kernel package that includes the upstream fix for the Bluetooth hci_uart lifecycle and synchronization issues. If exact fixed versions are not available from the input, obtain patched kernels from the relevant Linux distribution, device vendor, or kernel maintenance branch and prioritize systems that enable Bluetooth, HCI UART transports, serial-attached Bluetooth controllers, or untrusted local workloads. Where immediate patching is not possible, reduce exposure by disabling Bluetooth support if not required, blacklisting unused Bluetooth HCI UART-related modules where operationally safe, restricting local shell/container access, limiting access to TTY and Bluetooth device nodes, and applying normal kernel hardening controls such as module-loading restrictions, lockdown mode, SELinux/AppArmor policy, and least-privilege user access. Mitigations should be treated as temporary because the defect is in kernel synchronization and object lifetime handling.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel package includes the vendor fix for CVE-2026-46275 or the corresponding upstream hci_uart patch. Validate that the host has booted into the patched kernel, not merely installed it. Review vendor changelogs or kernel source to confirm the hci_uart changes: PROTO_READY is cleared before write_work cancellation, cancel_work_sync() is used on write_work paths, protocol close occurs before hci_free_dev(), and hci_uart_tty_receive() accesses hdev under the appropriate proto_lock read-side critical section. For exposure assessment, check whether Bluetooth support and HCI UART drivers are present or loaded, and whether systems expose relevant TTY/Bluetooth interfaces to untrusted users. After patching, monitor kernel logs for recurrence of hci_uart-related use-after-free, NULL pointer dereference, double-free, KASAN, or kernel oops messages during Bluetooth attach/detach and suspend/resume workflows.

Typical attack path

1. Obtain local execution on a vulnerable Linux system with access to relevant Bluetooth HCI UART or TTY interfaces.
2. Determine whether the kernel includes the vulnerable hci_uart lifecycle behavior and whether Bluetooth HCI UART support is available or loadable.
3. Trigger HCI UART initialization, partial setup, hangup, close, receive, or protocol timer activity in carefully timed sequences.
4. Cause hci_uart_tty_close(), hci_uart_close(), write_work, init_ready, or protocol callbacks to race with object teardown.
5. Force a stale hci_uart or hci_dev pointer to be dereferenced after free, or trigger a double-free of transmit buffers.
6. Use the resulting kernel memory corruption for denial of service or attempt to shape heap state for privilege escalation.

How to detect it

To assess whether this was already exploited, review kernel logs, persistent journald records, crash dumps, pstore records, audit logs, and endpoint telemetry for Bluetooth HCI UART-related crashes or memory-safety reports. Useful sources include /var/log/kern.log, /var/log/messages, journalctl -k output, systemd-coredump metadata, kdump/vmcore records, /sys/fs/pstore contents, EDR process lineage, and auditd records showing local users or processes interacting with Bluetooth, rfkill, hciattach/btattach, TTY devices, or module-loading paths shortly before a crash. Look for repeated kernel oopses, KASAN use-after-free reports, NULL pointer dereferences, general protection faults, double-free reports, or panics with call traces containing hci_uart functions such as hci_uart_tty_close, hci_uart_close, hci_uart_tty_receive, hci_uart_tx_wakeup, write_work, or init_ready. Absence of these artifacts does not prove non-exploitation because a successful local privilege-escalation attempt may avoid obvious crashes, but repeated Bluetooth-related kernel faults are a strong signal for investigation.

• Bluetooth: hci_uart
• BUG: KASAN: use-after-free
• BUG: KASAN: null-ptr-deref
• use-after-free in hci_uart
• NULL pointer dereference
• double free
• kernel BUG at drivers/bluetooth/hci_uart.c
• drivers/bluetooth/hci_uart.c
• hci_uart_tty_close
• hci_uart_close
• hci_uart_tty_receive
• hci_uart_tx_wakeup
• hci_uart_flush
• hci_free_dev
• write_work
• init_ready
• HCI_UART_PROTO_READY
• general protection fault
• kernel panic
• Oops:

What your security team should do

• Inventory Linux systems that have Bluetooth enabled, HCI UART support, serial-attached Bluetooth controllers, or workloads with untrusted local code execution.
• Prioritize patching multi-user servers, developer workstations, endpoint fleets, embedded Linux devices, kiosks, and container hosts where local privilege escalation would materially increase risk.
• Deploy vendor-provided kernel updates and ensure systems reboot into the fixed kernel version.
• Temporarily disable Bluetooth or unused HCI UART transports on systems where the functionality is not required.
• Restrict access to local device nodes, TTY interfaces, module loading, and Bluetooth management capabilities to trusted administrators only.
• Add monitoring for Bluetooth hci_uart-related kernel oops, KASAN, NULL pointer dereference, double-free, and panic events.
• Review recent kernel crash dumps and system logs for signs of repeated hci_uart lifecycle crashes that could indicate exploit development or local probing.
• Because this is not KEV-listed and has low EPSS in the provided data, handle through normal kernel patch management unless the environment has high local-code-execution exposure or critical Bluetooth-dependent operations.