CVE-2026-46056

What it actually does

CVE-2026-46056 is a use-after-free flaw in the Linux kernel Bluetooth stack, specifically in Secure Simple Pairing passkey event handling within hci_user_passkey_notify_evt() and hci_keypress_notify_evt(). The vulnerable code can look up an HCI connection and then continue accessing fields without holding the required hci_dev lock for the full lifetime of that access. If the connection object is freed concurrently, subsequent access may dereference freed kernel memory. Depending on timing, kernel configuration, memory layout, and heap state, this can cause a Bluetooth subsystem crash, kernel panic, information disclosure, memory corruption, or potentially kernel-level code execution.

Why it matters to the business

Systems with Bluetooth enabled and vulnerable Linux kernel versions may be exposed to nearby attackers because exploitation is adjacent-network rather than internet-routable. Successful exploitation could disrupt endpoints, kiosks, embedded devices, industrial systems, laptops, or servers with active Bluetooth adapters through crashes or loss of availability, and in a worst case could allow compromise at kernel privilege. Although EPSS is currently low and there is no known CISA KEV listing or public exploit maturity reported, the CVSS severity is high because exploitation requires no authentication or user interaction once an attacker is within Bluetooth range.

How an attack unfolds

An attacker must be within Bluetooth radio range of a vulnerable Linux system with Bluetooth enabled and reachable. The attacker initiates or manipulates Bluetooth pairing-related traffic involving Secure Simple Pairing passkey notification or keypress notification events. By carefully timing connection setup, notification handling, and disconnection or state changes, the attacker attempts to win a race where the kernel Bluetooth HCI event handler retrieves an hci_conn object while another execution path frees that connection. If the vulnerable handler continues using the freed connection object, the kernel may access stale memory. A reliable exploit would likely require repeated attempts and heap grooming to shape freed kernel memory; the most likely observable outcomes are Bluetooth instability, kernel warnings, oopses, or system crashes, while advanced exploitation could target privilege escalation or kernel code execution.

How to fix it

Apply the vendor-provided Linux kernel update that includes the Bluetooth hci_event locking fix for hci_user_passkey_notify_evt() and hci_keypress_notify_evt(). Because fixed package versions were not provided in the input, use the relevant distribution or appliance advisory to identify the first non-vulnerable kernel build for each platform. Reboot into the patched kernel after installation; merely installing a kernel package is not sufficient if the system continues running an older kernel. If immediate patching is not possible, reduce exposure by disabling Bluetooth, unloading Bluetooth kernel modules where operationally safe, disabling pairing/discoverability, blocking unauthorized physical proximity to sensitive systems, and limiting use of Bluetooth adapters on high-value Linux assets.

How to confirm the fix worked

Confirm the running kernel is the remediated build, not only that an updated package is installed. On Linux systems, compare `uname -r` and package-manager output against the distribution advisory for this issue. Verify that the patched source or vendor changelog includes the Bluetooth HCI event fix that extends hci_dev_lock coverage around hci_conn usage in hci_user_passkey_notify_evt() and hci_keypress_notify_evt(). Validate mitigation by confirming Bluetooth is disabled where required using service state, rfkill status, and loaded module checks. For exposure assessment, inventory systems with active Bluetooth controllers, loaded bluetooth/btusb modules, and kernels older than the vendor-fixed release.

Typical attack path

1. Identify a vulnerable Linux device with Bluetooth enabled and within radio range.
2. Initiate Bluetooth discovery, connection, or pairing interactions with the target device.
3. Trigger Secure Simple Pairing passkey notification or keypress notification event handling in the target kernel.
4. Create a race by causing connection state changes or teardown while the kernel handler is still using the HCI connection object.
5. Attempt to cause use-after-free memory access in the Bluetooth HCI event path.
6. Repeat and tune timing to achieve a crash, information leak, memory corruption, or possible kernel-level execution.

How to detect it

Review kernel logs, system journals, crash dumps, and endpoint telemetry for signs of Bluetooth-related kernel memory corruption or crashes. Relevant sources include `dmesg`, `/var/log/kern.log`, `/var/log/messages`, `journalctl -k`, system crash dump directories such as `/var/crash`, and kernel sanitizer output if enabled. Look for oopses, panics, KASAN reports, slab corruption, general protection faults, or NULL/unhandled page faults involving the Bluetooth stack, HCI event handling, hci_user_passkey_notify_evt, hci_keypress_notify_evt, hci_event, hci_conn, bluetooth, btusb, or hci_core. Also review Bluetooth daemon logs for unusual repeated pairing attempts, passkey notification activity, connection churn, or unexpected nearby device interactions around the time of any kernel fault. Because this is a race-condition memory safety issue, successful exploitation may leave no durable file artifact; absence of obvious indicators does not prove non-exploitation.

• hci_user_passkey_notify_evt
• hci_keypress_notify_evt
• Bluetooth: hci_event
• hci_conn
• KASAN: use-after-free
• BUG: KASAN: use-after-free
• general protection fault
• kernel BUG at
• Oops:
• Kernel panic
• Unable to handle kernel paging request
• Bluetooth: hci0
• Bluetooth: hci
• btusb
• bluetoothd
• /var/log/kern.log
• /var/log/messages
• /var/crash
• journalctl -k

What your security team should do

• Prioritize patching Linux endpoints, embedded devices, and appliances with Bluetooth enabled, especially systems in public, shared, or physically accessible locations.
• Where Bluetooth is not required, disable it through BIOS/UEFI, operating-system policy, rfkill, service configuration, or module denylisting.
• Create an inventory of Linux systems with active Bluetooth adapters and correlate it with kernel version data to identify exposure.
• Monitor for kernel oops, panic, KASAN, use-after-free, and Bluetooth HCI event anomalies on systems that cannot be patched immediately.
• Treat unexplained Bluetooth-related kernel crashes as potentially suspicious, especially if they occur repeatedly or near sensitive facilities.
• Track Linux distribution advisories for exact fixed kernel package versions and ensure systems reboot into the patched kernel.
• Because the issue is not currently in CISA KEV and EPSS is low, balance urgency against exposure: internet-facing prioritization is less relevant, but physical proximity and Bluetooth usage should drive risk ranking.