CVE-2026-43019

What it actually does

CVE-2026-43019 is a local Linux kernel use-after-free flaw in the Bluetooth HCI connection handling path, specifically in set_cig_params_sync. A Bluetooth hci_conn object can be looked up and then accessed without holding the required hdev lock, allowing another kernel execution path to delete or modify the same object concurrently. This race condition can result in stale pointer use, memory corruption, kernel crash, or potentially local privilege escalation if an attacker can reliably shape kernel memory and trigger the vulnerable Bluetooth code path. The CVSS vector indicates local access with low attack complexity, low privileges required, no user interaction, and high confidentiality, integrity, and availability impact.

Why it matters to the business

Successful exploitation could allow a local low-privileged user or compromised process on a Linux system with the affected Bluetooth kernel functionality enabled to crash the host or potentially gain elevated privileges. The most likely operational impact is local denial of service through kernel panic, while the higher-risk scenario is full host compromise through kernel-level code execution. Because this is not listed in CISA KEV, has no known public exploit maturity, and has a low, flat EPSS score, widespread active exploitation is not currently indicated; however, kernel privilege-escalation issues should still be prioritized on multi-user systems, developer workstations, laptops, kiosks, edge devices, and servers where Bluetooth modules are present or loadable.

How an attack unfolds

An attacker first obtains local code execution with low privileges on a Linux system running an affected kernel and with Bluetooth support available. The attacker then interacts with Bluetooth HCI functionality in a way that exercises Connected Isochronous Group parameter handling and creates a race between set_cig_params_sync and concurrent hci_conn deletion or modification. By repeatedly triggering the race, the attacker attempts to cause the kernel to access a freed hci_conn object. A simple exploit may only cause memory corruption and crash the system, while a more advanced exploit would attempt to groom kernel heap allocations so the freed memory is replaced with attacker-influenced data, enabling privilege escalation or kernel control-flow manipulation. There is currently no indication from the supplied data that this vulnerability is being exploited by named threat actors, ransomware campaigns, or CISA KEV-tracked activity.

How to fix it

Upgrade the Linux kernel to a vendor-provided fixed release that includes the Bluetooth hci_conn locking correction for set_cig_params_sync. Because no exact fixed versions were provided, use the distribution or appliance vendor advisory for CVE-2026-43019 and install the latest available kernel security update. Reboot systems after applying the kernel update to ensure the fixed kernel is running. Where immediate patching is not possible, reduce exposure by disabling Bluetooth if it is not required, preventing automatic loading of Bluetooth kernel modules where operationally safe, and restricting local shell access to trusted users. Potential mitigations include disabling the Bluetooth service stack, blocking Bluetooth device access for untrusted users, and blacklisting Bluetooth-related modules such as bluetooth, btusb, hci_uart, and related drivers only after validating business impact.

How to confirm the fix worked

Confirm the running kernel version, not just the installed package version, after remediation using standard OS tooling such as uname -a and the distribution package manager. Validate against the vendor advisory to ensure the running kernel contains the fix for the Bluetooth hci_conn set_cig_params_sync race. Check whether Bluetooth is enabled or modules are loaded using tools such as lsmod, modinfo, rfkill, bluetoothctl, systemctl status bluetooth, and kernel configuration evidence where available. If Bluetooth was disabled as a mitigation, verify that Bluetooth services are stopped, adapters are blocked or absent, and relevant modules are not loaded after reboot. For fleet validation, inventory Linux hosts with Bluetooth-capable hardware, loaded Bluetooth modules, or kernels predating the vendor-fixed release, and confirm successful reboot into the patched kernel.

Typical attack path

1. Gain local access to an affected Linux system as an unprivileged or low-privileged user.
2. Confirm Bluetooth kernel support is enabled, present, or loadable and that the vulnerable code path is reachable.
3. Trigger Bluetooth HCI connection and CIG parameter operations that exercise set_cig_params_sync.
4. Create a timing race where an hci_conn object is freed or modified while the vulnerable function still accesses it without the required hdev lock.
5. Repeat the race to cause a kernel crash or to improve reliability for memory corruption.
6. If exploitation is advanced, groom kernel memory so reuse of the freed object enables privilege escalation or arbitrary kernel behavior.

How to detect it

To assess possible prior exploitation, focus on evidence of local kernel memory corruption, Bluetooth subsystem anomalies, and privilege escalation following Bluetooth activity. Review kernel logs from journald, dmesg, /var/log/kern.log, /var/log/messages, and crash dump infrastructure for use-after-free, general protection fault, KASAN, slab, BUG, WARNING, panic, or oops messages referencing Bluetooth, HCI, hci_conn, CIG, ISO, or set_cig_params_sync. Correlate crashes or oops events with local user sessions, new processes, sudo/su activity, privilege changes, and Bluetooth management commands. Look for unexpected loading of Bluetooth modules on systems where Bluetooth is normally unused. If kernel crash dumps are collected, inspect stack traces for Bluetooth HCI connection paths and memory corruption near set_cig_params_sync. There are no supplied public exploit tool indicators, threat actor artifacts, ransomware links, or network indicators; detection should therefore be behavior- and artifact-based rather than signature-based.

• set_cig_params_sync
• hci_conn
• Bluetooth: hci_conn
• use-after-free
• KASAN: use-after-free
• BUG: KASAN
• general protection fault
• kernel BUG
• kernel panic
• Oops:
• Bluetooth:
• HCI
• CIG
• ISO
• btusb
• hci_uart
• bluetooth

What your security team should do

• Prioritize kernel updates on Linux endpoints and systems where local users, containers with elevated host interaction, remote-access users, or untrusted workloads may obtain local execution.
• Patch laptops, workstations, kiosks, lab systems, edge devices, and any Linux servers with Bluetooth modules loaded or Bluetooth hardware exposed before lower-risk systems without Bluetooth functionality.
• Disable Bluetooth services and prevent Bluetooth kernel module loading where Bluetooth is unnecessary, especially on servers and hardened systems.
• Review local privilege escalation monitoring for unexpected root shells, suspicious setuid binary creation, kernel crash events, or anomalous Bluetooth/HCI activity.
• Monitor vendor advisories for exact fixed kernel versions and backports, as Linux distributions may fix this issue without changing to an upstream kernel version that is obviously newer.
• Because EPSS is low and no KEV or exploit maturity is reported, handle as a standard high-severity kernel hardening and patch-management item rather than an active mass-exploitation emergency unless new exploit intelligence emerges.