CVE-2026-43022

What it actually does

This is a local denial-of-service flaw in the Linux kernel Bluetooth HCI synchronization logic. The vulnerable code path did not correctly report when a duplicate HCI command synchronization queue item already existed, which could cause callers to assume callbacks would run when they would not. That mismatch could leak kernel resources. A local user able to exercise the affected Bluetooth code path may be able to repeatedly trigger the condition and exhaust resources, degrading or crashing the system. The impact is availability only; the provided scoring does not indicate confidentiality or integrity impact.

Why it matters to the business

Successful exploitation can make affected Linux systems unstable or unavailable, particularly systems with enabled Bluetooth support or workloads where local users, containers, desktop sessions, or service accounts can interact with Bluetooth interfaces. The CVSS score is moderate, EPSS is very low and flat, it is not in CISA KEV, and no exploit maturity is reported, so this should generally be handled through normal kernel patch cycles unless the system is multi-user, exposed to untrusted local users, or depends on Bluetooth availability for operations.

How an attack unfolds

An attacker first needs local access to an affected Linux system with sufficient ability to interact with the Bluetooth subsystem. They then trigger Bluetooth HCI synchronization operations in a way that causes the same command synchronization item to be queued more than once. On vulnerable kernels, the duplicate queue condition is not reported distinctly, so the caller may wait for callbacks or cleanup paths that are never invoked. By repeating this behavior, the attacker can cause kernel-side resource leakage. Over time, the leak may exhaust memory or related kernel resources, resulting in Bluetooth service failure, degraded host performance, kernel warnings, out-of-memory events, or a system crash/reboot.

How to fix it

Upgrade to a Linux kernel version that includes the upstream fix for the Bluetooth hci_sync change where hci_cmd_sync_queue_once() returns -EEXIST when a queue item already exists and all call sites handle that return value correctly. No exact fixed package versions were provided, so use distribution vendor advisories for the applicable kernel package and confirm the patch is included in the shipped kernel. If immediate patching is not possible, reduce exposure by disabling Bluetooth where it is not required, preventing untrusted local users from accessing Bluetooth management interfaces, restricting local shell/container access on affected systems, and monitoring for abnormal Bluetooth and memory-exhaustion behavior. Kernel live patching may be appropriate where supported, but a reboot into the fixed kernel is usually required to fully remediate kernel vulnerabilities.

How to confirm the fix worked

Confirm remediation by verifying the running kernel version, not just the installed package version, after patching and rebooting if required. Check vendor advisories or kernel changelogs for the Bluetooth hci_sync fix related to hci_cmd_sync_queue_once() returning -EEXIST on duplicate queue items. On source-based or custom kernels, confirm the patched behavior is present in the Bluetooth HCI synchronization code and that affected call sites handle -EEXIST. Validate exposure reduction by confirming Bluetooth is disabled or unavailable where not needed, for example by checking service state, loaded Bluetooth modules, and available HCI devices. Where safe test coverage exists, run Bluetooth regression tests and monitor dmesg/journal logs for new Bluetooth HCI warnings, memory leaks, or crashes.

Typical attack path

1. Gain local code execution or an interactive local session on an affected Linux host.
2. Identify that Bluetooth support is present and enabled, or load/use Bluetooth functionality where permitted.
3. Exercise Bluetooth HCI management or command paths that enqueue HCI synchronization work.
4. Trigger duplicate queue-item conditions so vulnerable callers fail to release resources correctly.
5. Repeat the trigger to accumulate leaked kernel resources.
6. Cause service degradation, out-of-memory behavior, kernel instability, or host denial of service.

How to detect it

There is no known public exploit pattern or unique network indicator for this local kernel denial-of-service issue. Detection should focus on post-exploitation symptoms and local activity preceding them. Review kernel logs from dmesg, journald, syslog, crash dumps, and monitoring telemetry for Bluetooth HCI warnings, repeated Bluetooth resets, kernel memory pressure, out-of-memory killer activity, soft lockups, panics, or unexpected reboots. Correlate those events with local user logins, sudo activity, container starts, execution of Bluetooth utilities, DBus Bluetooth management calls, or unusual access to HCI devices. On systems with auditd or EDR, look for repeated execution of Bluetooth management tools such as bluetoothctl, btmgmt, hciconfig, hcitool, or custom binaries interacting with AF_BLUETOOTH sockets immediately before memory exhaustion or host instability. Because the issue is a resource leak, absence of a distinctive artifact does not prove non-exploitation; prioritize correlation between Bluetooth activity and resource exhaustion.

• hci_cmd_sync_queue_once
• hci_cmd_sync
• Bluetooth: hci
• Bluetooth: hci0
• Out of memory: Killed process
• oom-killer
• Kernel panic - not syncing
• BUG: unable to handle kernel
• soft lockup
• bluetoothctl
• btmgmt
• hciconfig
• hcitool

What your security team should do

• Prioritize patching affected Linux kernels on multi-user systems, developer workstations, shared jump hosts, kiosk/desktop fleets, and systems where untrusted local code can run.
• Use the normal kernel update process for lower-risk servers with Bluetooth disabled, but ensure they are still tracked to closure.
• Disable Bluetooth services, block Bluetooth kernel modules, or remove Bluetooth hardware access on systems that do not require it.
• Confirm systems have rebooted into the fixed kernel after updates; do not rely solely on package inventory.
• Add monitoring for kernel out-of-memory events, Bluetooth HCI errors, repeated Bluetooth subsystem resets, and unexpected local use of Bluetooth tooling.
• Review local access controls, container device passthrough, and group memberships that allow interaction with Bluetooth devices.
• Because EPSS is very low, flat over 30 days, not KEV-listed, and no public exploit maturity is reported, do not treat this as internet-facing emergency work unless local untrusted access is common in the environment.