CVE-2026-64206

What it actually does

This is a race-condition/deadlock flaw in the Linux kernel Bluetooth L2CAP connection teardown path. During l2cap_conn_del(), the kernel takes conn->lock and then calls cancel_work_sync() for pending_rx_work; however, the pending_rx_work handler, process_pending_rx(), also attempts to acquire the same lock. If teardown occurs while the pending receive worker is queued or running, the teardown path can wait for a worker that is itself blocked on the lock held by teardown, producing a circular lock dependency and potential deadlock. The practical technical impact is denial of service affecting Bluetooth/L2CAP handling and, depending on kernel configuration and workload, possible kernel task hangs or broader system instability. There is no indication from the provided data that this enables privilege escalation, code execution, or information disclosure.

Why it matters to the business

Systems using vulnerable Linux kernels with Bluetooth enabled may be susceptible to service disruption if an attacker can reach the Bluetooth interface and manipulate L2CAP connection timing. The most likely business impact is device instability, degraded Bluetooth functionality, hung kernel workers, or a system requiring manual recovery or reboot. This is not currently listed in CISA KEV, is not known to be used in ransomware campaigns, has no reported exploit maturity, and has a low EPSS score, so broad internet-scale exploitation is unlikely; however, exposed workstations, embedded devices, kiosks, industrial endpoints, and appliances that depend on Bluetooth availability may still face operational disruption.

How an attack unfolds

An attacker would need proximity or another path to interact with the target system's Bluetooth stack. They would initiate or influence an L2CAP connection so that receive processing is queued through the pending_rx_work path. The attacker then causes connection teardown at a timing point where l2cap_conn_del() attempts to cancel that pending work while holding conn->lock. If process_pending_rx() is already running or scheduled and attempts to take the same mutex, the kernel can enter a deadlock condition. Successful exploitation would likely manifest as Bluetooth stack hangs, kernel lockup warnings, blocked workqueues, or system instability rather than attacker-controlled code execution.

How to fix it

Apply a Linux kernel update that includes the fix for the Bluetooth L2CAP pending_rx_work teardown ordering issue. The corrected behavior cancels pending_rx_work before taking conn->lock, avoiding the lock inversion. Because no exact affected products or fixed package versions were provided, use vendor kernel advisories for the relevant distribution, appliance, or device firmware and upgrade to the first kernel release that contains the upstream fix. Where immediate patching is not possible, reduce exposure by disabling Bluetooth on systems that do not require it, blocking or administratively disabling Bluetooth adapters, limiting physical access to Bluetooth-enabled devices, and prioritizing updates for devices where Bluetooth is enabled in production or operationally critical.

How to confirm the fix worked

Confirm the running kernel includes the vendor patch for the Bluetooth L2CAP l2cap_conn_del()/pending_rx_work deadlock fix. Validate by checking the installed kernel package or firmware version against the operating system or device vendor advisory. On source-built kernels, verify that the L2CAP teardown path cancels pending_rx_work before acquiring conn->lock. After remediation, test that Bluetooth pairing, L2CAP connection setup, and disconnect operations function normally and do not generate lockdep, hung task, workqueue, or Bluetooth stack deadlock warnings in kernel logs. Also verify that Bluetooth is disabled on systems where mitigation requires it.

Typical attack path

1. Identify a Linux system with Bluetooth enabled and a vulnerable kernel build.
2. Establish Bluetooth proximity or otherwise gain the ability to interact with the target Bluetooth L2CAP stack.
3. Trigger L2CAP connection setup so pending receive work is queued via pending_rx_work.
4. Force or race connection teardown while the pending receive worker is queued or running.
5. Cause l2cap_conn_del() and process_pending_rx() to contend on conn->lock in the vulnerable order.
6. Induce a deadlock, resulting in Bluetooth subsystem disruption, kernel worker hangs, or possible system instability.

How to detect it

To determine whether this issue may have already been triggered, review kernel and system logs for Bluetooth L2CAP errors, lockdep warnings, circular locking dependency messages, hung task reports, blocked workqueue messages, and kernel traces involving process_pending_rx, l2cap_conn_del, pending_rx_work, l2cap_conn_ready, or cancel_work_sync. Useful sources include dmesg, journalctl kernel logs, /var/log/kern.log, /var/log/messages, crash dumps, kdump/vmcore analysis, and endpoint telemetry that captures kernel warnings or reboots. Look for unexplained Bluetooth outages, system freezes, watchdog resets, or reboots occurring shortly after Bluetooth pairing, connection, or disconnection activity. Because this vulnerability produces a denial-of-service style deadlock rather than a durable malware artifact, absence of persistent files or processes does not rule out triggering; detection is primarily based on kernel log artifacts and timing correlation with Bluetooth activity.

• WARNING: possible circular locking dependency detected
• *** DEADLOCK ***
• process_pending_rx+
• l2cap_conn_del
• l2cap_conn_ready
• pending_rx_work
• cancel_work_sync(&conn->pending_rx_work)
• mutex_lock(&conn->lock)
• Bluetooth: L2CAP
• workqueue: process_pending_rx
• INFO: task blocked for more than
• BUG: workqueue lockup
• kernel: Bluetooth:
• kernel: INFO: task
• kernel: WARNING: possible circular locking dependency detected

What your security team should do

• Inventory Linux systems, appliances, embedded devices, and endpoints with Bluetooth enabled and prioritize those with physical exposure or operational dependence on Bluetooth.
• Patch affected Linux kernels through distribution, device, or firmware update channels once fixed builds are available.
• If patching is delayed, disable Bluetooth services and adapters on systems that do not explicitly require Bluetooth functionality.
• Monitor kernel logs for lockdep circular dependency warnings, hung task messages, blocked workqueues, and Bluetooth L2CAP errors related to process_pending_rx or l2cap_conn_del.
• For high-assurance environments, restrict physical access around sensitive Bluetooth-enabled assets and enforce policies that prevent unauthorized Bluetooth pairing or use.
• Track vendor advisories because affected product and fixed-version information may vary by Linux distribution, long-term-support kernel branch, and downstream appliance firmware.