CVE-2026-43119

What it actually does

This is a local Linux kernel race condition in the Bluetooth HCI command synchronization path. Multiple kernel execution contexts access hdev->req_status concurrently across different workqueues and event/cancel paths without consistent synchronization; the fix adds READ_ONCE()/WRITE_ONCE() annotations to prevent compiler and CPU access assumptions from causing incorrect behavior. Successful exploitation is expected to affect availability only, potentially causing Bluetooth subsystem malfunction, kernel warnings, hangs, or a system crash. The CVSS vector indicates local access with low privileges is required, with no expected confidentiality or integrity impact.

Why it matters to the business

Systems running affected Linux kernels with Bluetooth enabled may be susceptible to local denial of service, which can interrupt endpoint, workstation, laptop, embedded, or IoT operations and require a reboot or hands-on recovery. The risk is moderated by the need for local access, low EPSS, no known public exploit maturity, and no CISA KEV listing, but Linux’s broad deployment means organizations should still remediate through normal kernel patch cycles, prioritizing exposed multi-user systems and devices where Bluetooth is enabled and operational continuity matters.

How an attack unfolds

An attacker first obtains local execution on a vulnerable Linux system, such as through a local user account, compromised low-privilege process, or code running in a context that can interact with Bluetooth functionality. The attacker then repeatedly exercises Bluetooth HCI management or command paths to force overlap between command submission, completion, cancellation, and connection-abort handling. Because the affected kernel code accesses hdev->req_status from multiple concurrent contexts without the corrected one-time access annotations, a race may cause the kernel to observe stale, fused, or reordered state. If triggered successfully, the attacker can destabilize the Bluetooth stack or the kernel, resulting in a denial-of-service condition such as a hang, crash, or reboot. There is currently no indication from the provided data of known exploitation in the wild, ransomware use, or public exploit maturity.

How to fix it

Upgrade to a Linux kernel build from the operating system or appliance vendor that includes the upstream Bluetooth hci_sync fix adding READ_ONCE()/WRITE_ONCE() annotations around hdev->req_status accesses. Because no exact fixed package versions were provided, use vendor advisories and changelogs for the relevant distribution, appliance, or kernel branch and look for this CVE or the fix titled similar to "Bluetooth: hci_sync: annotate data-races around hdev->req_status." Reboot after installing the fixed kernel to ensure the patched kernel is running. If immediate patching is not possible, reduce exposure by disabling Bluetooth where it is not required, blocking or unloading Bluetooth-related modules such as bluetooth and btusb where operationally safe, restricting local shell access, limiting untrusted workloads on affected hosts, and monitoring for kernel instability related to Bluetooth HCI operations.

How to confirm the fix worked

Confirm the running kernel, not only the installed package, has been updated by checking uname -r and comparing it with the vendor-fixed kernel release. Review distribution package metadata, changelogs, or kernel source patches for references to this CVE, hci_sync, hdev->req_status, READ_ONCE(), or WRITE_ONCE(). Verify the system has been rebooted into the fixed kernel after patching. If Bluetooth is disabled as a mitigation, confirm Bluetooth controllers are not active and that relevant modules or services are not loaded or started. For source-based or custom kernels, inspect the Bluetooth HCI synchronization code to ensure concurrent reads and writes of hdev->req_status use READ_ONCE()/WRITE_ONCE() or equivalent vendor backports.

Typical attack path

1. Gain local code execution or an interactive low-privilege account on a vulnerable Linux host.
2. Confirm Bluetooth support is present and enabled, or load/interact with the Bluetooth subsystem if permitted.
3. Generate repeated Bluetooth HCI command, cancellation, completion, or connection-abort activity to increase concurrency across kernel workqueues.
4. Attempt to trigger the hdev->req_status race condition during overlapping Bluetooth operations.
5. Cause a kernel availability failure such as Bluetooth subsystem lockup, kernel hang, panic, or forced reboot.

How to detect it

There is no reliable unique network indicator for this issue because exploitation is local and the failure mode resembles a kernel stability bug. To assess possible prior exploitation, review kernel logs, persistent journald records, crash dumps, pstore, kdump/vmcore data, endpoint telemetry, and reboot history for crashes or hangs involving the Linux Bluetooth HCI stack. Focus on stack traces or warnings containing hci_sync, hci_cmd_sync, hci_cmd_sync_complete, hci_cmd_sync_cancel, hci_abort_conn, hci_send_cmd_sync, hdev->req_status, bluetooth, or btusb. Correlate those events with local logins, privilege changes, process execution, or Bluetooth management utilities such as bluetoothctl, btmgmt, hciconfig, rfkill, or custom binaries interacting with Bluetooth sockets. Also review auditd or EDR telemetry for suspicious local users repeatedly invoking Bluetooth tooling shortly before kernel warnings, panics, watchdog resets, or unexpected reboots. Absence of these artifacts does not prove non-exploitation, because a successful denial-of-service may leave limited forensic evidence if logs were not persisted before the crash.

• hci_sync
• __hci_cmd_sync_sk
• hci_send_cmd_sync
• hci_cmd_sync_complete
• hci_cmd_sync_cancel
• hci_cmd_sync_cancel_sync
• hci_abort_conn
• hdev->req_status
• Bluetooth: hci
• btusb
• bluetoothctl
• btmgmt
• hciconfig
• rfkill
• kernel panic
• watchdog: BUG: soft lockup
• INFO: task
• blocked for more than
• BUG: unable to handle kernel
• general protection fault

What your security team should do

• Inventory Linux systems with Bluetooth enabled or Bluetooth-capable hardware, prioritizing laptops, workstations, edge devices, embedded systems, and multi-user Linux hosts.
• Patch affected systems through the normal kernel update process, prioritizing systems that allow local user access or run untrusted workloads.
• Reboot patched systems and verify the running kernel version is the fixed version, not an older vulnerable kernel still active after package installation.
• Disable Bluetooth on servers and other systems where it is not operationally required.
• Restrict local access and untrusted code execution on systems that cannot be patched promptly.
• Monitor kernel, system, and endpoint telemetry for Bluetooth HCI-related crashes, hangs, repeated Bluetooth command activity, or unexplained reboots.
• Track vendor advisories for exact fixed kernel versions because fixed_versions were not provided in the input.