CVE-2026-43018

What it actually does

CVE-2026-43018 is a Linux kernel Bluetooth use-after-free flaw in the handling of LE Remote Connection Parameter Request events. The vulnerable path can look up an hci_conn object and access its fields without holding the required hci_dev lock for the full duration of use. If another kernel path frees the connection object concurrently, the Bluetooth event handler may dereference freed memory. Because this occurs in kernel context, successful exploitation can potentially cause kernel memory corruption, denial of service through a crash, or, depending on heap layout and exploit reliability, privilege escalation or arbitrary kernel-code execution. The attack vector is adjacent-network Bluetooth, meaning an attacker generally needs to be within Bluetooth radio range of an affected system with Bluetooth enabled.

Why it matters to the business

An attacker physically near an affected Linux system could potentially crash the machine or compromise it through the Bluetooth stack without needing credentials or user interaction. This is most relevant for laptops, workstations, embedded Linux devices, kiosks, industrial systems, medical devices, and IoT products that keep Bluetooth enabled. Although the current EPSS is low at 0.00256, has been flat over 30 days, is not in CISA KEV, and has no known public exploit maturity, the CVSS score is high because exploitation could affect confidentiality, integrity, and availability at the operating-system level.

How an attack unfolds

An attacker first positions a Bluetooth-capable device within radio range of a vulnerable Linux host with Bluetooth enabled. The attacker initiates or manipulates a Bluetooth Low Energy connection sequence and sends LE Remote Connection Parameter Request events timed around connection teardown or state changes. On a vulnerable kernel, the event handler may continue using an hci_conn structure after another thread has freed it because the hci_dev lock does not cover all connection-object usage. If the race is won, the kernel dereferences stale memory. In the simplest case this causes a kernel oops, panic, Bluetooth subsystem failure, or host reboot. A more capable attacker may attempt to shape heap contents and timing so the freed object is replaced with attacker-influenced data, potentially converting the use-after-free into controlled memory corruption and kernel-level compromise. There are no known named threat actors, KEV listing, ransomware use, or mature public exploitation reported in the provided data.

How to fix it

Apply a vendor-provided Linux kernel update that includes the Bluetooth hci_event locking fix for hci_le_remote_conn_param_req_evt. Because exact fixed package versions were not provided, use the fixed kernel versions published by the relevant Linux distribution, appliance vendor, or device manufacturer for this CVE. Reboot into the patched kernel after installation; merely installing the package is insufficient if the system continues running the old kernel. Where immediate patching is not possible, reduce exposure by disabling Bluetooth entirely, blocking automatic Bluetooth startup, unloading or blacklisting Bluetooth kernel modules where operationally acceptable, disabling BLE services, and restricting physical proximity to sensitive systems. For embedded or appliance environments, obtain firmware images from the vendor that incorporate the corrected kernel. Treat mitigations as temporary because the underlying issue is in kernel memory-safety logic.

How to confirm the fix worked

Confirm the running kernel, not only the installed kernel package, is at a vendor-fixed level. Validate with distribution-specific package advisory tools and by checking the active kernel version after reboot. Confirm whether Bluetooth is enabled and whether Bluetooth kernel modules such as bluetooth, btusb, hci_uart, or related vendor drivers are loaded. On patched systems, verify the vendor advisory marks the installed kernel build as fixed for this CVE. If mitigation rather than patching is used, confirm Bluetooth adapters are disabled, blocked, or unavailable to the OS, and that Bluetooth services do not restart after reboot. For higher assurance, review kernel changelogs or source patches for the fix that extends the hci_dev_lock critical section around all hci_conn usage in hci_le_remote_conn_param_req_evt.

Typical attack path

1. Identify a Linux target with Bluetooth enabled and reachable within Bluetooth radio range.
2. Establish or interact with a Bluetooth Low Energy connection to the target.
3. Send crafted or precisely timed LE Remote Connection Parameter Request traffic.
4. Race the vulnerable event handler against connection cleanup so the hci_conn object is freed while still in use.
5. Trigger a use-after-free dereference in kernel Bluetooth code.
6. Cause a kernel crash or attempt further heap manipulation to gain kernel-level execution or privilege escalation.

How to detect it

Look for evidence of prior exploitation in kernel logs, system journals, crash dumps, endpoint telemetry, and Bluetooth service logs. Relevant sources include journalctl -k, /var/log/kern.log, /var/log/messages, /var/log/syslog, pstore/ramoops records, kdump/vmcore artifacts, ABRT/apport crash reports, and Bluetooth daemon logs. Focus on kernel oopses, panics, KASAN reports, slab use-after-free messages, general protection faults, or call traces involving hci_le_remote_conn_param_req_evt, hci_event, Bluetooth HCI, hci_conn, btusb, or hci_core. Correlate crash times with Bluetooth activity such as new BLE connections, repeated connection parameter update requests, unexpected adapter resets, or unknown nearby Bluetooth devices. Because exploitation is radio-proximity based, traditional network perimeter logs usually will not show the attack. Absence of logs does not prove absence of exploitation, especially if kernel crash logging, persistent journal storage, pstore, or kdump are not enabled.

• hci_le_remote_conn_param_req_evt
• hci_event
• hci_conn
• Bluetooth: hci
• KASAN: use-after-free
• BUG: KASAN: slab-use-after-free
• BUG: KASAN: use-after-free
• general protection fault
• kernel BUG
• Oops:
• Call Trace:
• btusb
• hci_core
• bluetoothd
• /var/log/kern.log
• /var/log/syslog
• /var/log/messages
• /sys/fs/pstore
• vmcore

What your security team should do

• Prioritize patching Bluetooth-enabled Linux laptops, workstations, kiosks, embedded devices, and other systems used in physically accessible or public spaces.
• Reboot systems after kernel updates and verify the active running kernel is the fixed kernel.
• Disable Bluetooth on systems that do not require it, especially servers and sensitive endpoints.
• Inventory Linux assets with Bluetooth hardware, loaded Bluetooth modules, or active bluetoothd services.
• Monitor kernel logs for Bluetooth-related crashes, KASAN use-after-free reports, general protection faults, and call traces referencing hci_le_remote_conn_param_req_evt or hci_event.
• For devices that cannot be patched quickly, apply compensating physical controls by limiting public or untrusted proximity to Bluetooth-enabled systems.
• Track vendor advisories for exact fixed kernel package versions because the input did not provide fixed versions.
• Do not over-prioritize based on active exploitation: the vulnerability is not currently KEV-listed, has no known ransomware association, and has a low, flat EPSS; prioritize based on Bluetooth exposure and operational criticality.