CVE-2026-43021

What it actually does

This is a local Linux kernel denial-of-service vulnerability in the Bluetooth HCI synchronization code. When hci_cmd_sync_queue_once() fails, the expected destroy callback is not invoked, causing references and memory associated with the failed operation to leak. A local user with the ability to exercise the affected Bluetooth code path can repeatedly trigger the failure condition and consume kernel memory or object references, potentially degrading Bluetooth functionality, causing system instability, or leading to an out-of-memory condition. The CVSS vector indicates local access, low attack complexity, low privileges required, no user interaction, and high availability impact, with no direct confidentiality or integrity impact.

Why it matters to the business

Successful exploitation can make affected Linux systems unstable or unavailable, especially systems where Bluetooth is enabled and untrusted or low-privileged local users can access Bluetooth functionality. The main operational risk is service disruption rather than data theft. Because this issue is not listed in CISA KEV, has no known exploit maturity, and has very low EPSS with no upward trend, broad active exploitation is not currently indicated; however, Linux kernel flaws can have wide operational reach because they affect many distributions, appliances, workstations, and embedded systems that inherit upstream kernel code.

How an attack unfolds

An attacker first obtains local, low-privileged access to an affected Linux system where the vulnerable Bluetooth kernel code is present and reachable. They then interact with Bluetooth/HCI functionality in a way that causes hci_cmd_sync_queue_once() to return an error. Due to the flaw, cleanup does not occur on that failure path, so references or memory are leaked. By repeatedly invoking the same failure path, the attacker can steadily consume kernel resources. Over time this may exhaust memory or reference counts, disrupt Bluetooth services, trigger kernel warnings, cause process termination by the out-of-memory killer, or destabilize the host. There is no indication from the supplied intelligence that this vulnerability is being used by named threat actors, ransomware campaigns, or public exploit tooling.

How to fix it

Apply a vendor-supplied Linux kernel update that includes the upstream Bluetooth hci_sync cleanup fix for this issue. No exact fixed package versions were provided in the input, so remediation should be tracked through the relevant Linux distribution, appliance vendor, or kernel-maintainer advisory. Where immediate patching is not possible, reduce exposure by disabling Bluetooth on systems that do not require it, removing or blacklisting Bluetooth kernel modules where operationally safe, restricting local shell access to trusted users, and limiting access to Bluetooth management interfaces and device nodes according to least privilege. Because this is a kernel issue, a reboot is typically required after installing the fixed kernel for the remediation to take effect.

How to confirm the fix worked

Confirm that each affected system is running a kernel build from the operating system or appliance vendor that includes the fix for the Bluetooth hci_sync leak on hci_cmd_sync_queue_once() failure. Validate by checking the running kernel version, installed kernel package changelog, vendor security advisory, or source commit history rather than relying only on package installation state. Confirm the system has rebooted into the fixed kernel. For systems where mitigation is used instead of patching, verify that Bluetooth is disabled, relevant Bluetooth kernel modules are not loaded, and Bluetooth management interfaces are not accessible to untrusted local users. Operational validation can include monitoring that repeated Bluetooth error conditions no longer cause steadily increasing kernel memory usage, Bluetooth reference leaks, OOM-killer events, or kernel warnings.

Typical attack path

1. Gain local low-privileged access to a Linux system running an affected kernel with Bluetooth support present.
2. Confirm that Bluetooth/HCI functionality is enabled or otherwise reachable from the local context.
3. Invoke Bluetooth/HCI operations that can cause hci_cmd_sync_queue_once() to fail.
4. Repeat the operation to trigger the unhandled cleanup path many times.
5. Accumulate leaked kernel memory or references until Bluetooth functionality degrades or the system becomes unstable.
6. Cause denial of service through resource exhaustion, out-of-memory conditions, service disruption, or host instability.

How to detect it

There are no known public exploit indicators, KEV listing, ransomware association, or named threat actors in the supplied intelligence. Detection should focus on evidence of local abuse of Bluetooth functionality followed by kernel resource exhaustion. Review kernel logs, system journal logs, Bluetooth daemon logs, audit logs, and endpoint telemetry for repeated Bluetooth/HCI errors, unusual local execution of Bluetooth management utilities, rapid memory growth, OOM-killer events, kernel warnings, or crashes. Correlate suspected events with local user sessions, sudo/use of privileged helper tools, container escape attempts, or repeated access to Bluetooth device nodes. On Linux systems, useful log sources include dmesg, journald, syslog, auditd, bluetoothd logs, EDR process telemetry, and kernel crash dumps. Because the vulnerability is a memory/reference leak rather than a payload-dropping exploit, durable file-based IOCs are unlikely; absence of specific IOCs does not prove non-exploitation.

• hci_cmd_sync_queue_once
• Bluetooth: hci
• bluetoothd
• /usr/bin/bluetoothctl
• /usr/bin/hciconfig
• /usr/bin/btmgmt
• /dev/rfkill
• /sys/class/bluetooth
• Out of memory: Killed process
• oom-killer
• kernel: Bluetooth
• BUG: memory leak
• WARNING: CPU
• slab out of memory

What your security team should do

• Prioritize patching shared workstations, multi-user Linux systems, kiosks, lab systems, developer machines, and any Linux host where untrusted local users may have shell or application-level access.
• Identify Linux assets with Bluetooth enabled or Bluetooth kernel modules loaded, and treat those as the highest-priority exposure group.
• Apply the relevant vendor kernel update and reboot into the fixed kernel; verify the active running kernel, not just installed packages.
• Where patching must be delayed, disable Bluetooth if it is not business-critical and restrict local access to trusted users only.
• Monitor kernel logs for Bluetooth HCI errors, memory pressure, OOM-killer activity, and repeated local Bluetooth operations that coincide with resource exhaustion.
• Do not treat this as an internet-exposed remote code execution issue; prioritize according to local-access risk, asset criticality, and Bluetooth usage.
• Track vendor advisories for exact fixed kernel versions because no fixed versions were supplied in the provided vulnerability data.