CVE-2026-64206 in Linux
Summary
by MITRE • 07/20/2026
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: L2CAP: cancel pending_rx_work before taking conn->lock
l2cap_conn_del() takes conn->lock and then calls cancel_work_sync() for pending_rx_work. process_pending_rx() takes the same mutex, so teardown can deadlock against the worker it is flushing.
This issue was found by our static analysis tool and then manually reviewed against the current tree.
The grounded PoC kept the l2cap_conn_ready() -> queue_work(..., &conn->pending_rx_work) submit path, the l2cap_conn_del() -> cancel_work_sync(&conn->pending_rx_work) teardown path, and the process_pending_rx() -> mutex_lock(&conn->lock) worker edge. Lockdep
WARNING: possible circular locking dependency detected process_pending_rx+0x21/0x2a [vuln_msv]
l2cap_conn_del.constprop.0+0x3f/0x4e [vuln_msv]
*** DEADLOCK ***
Cancel pending_rx_work before taking conn->lock, matching the existing lock-before-drain ordering used for the two delayed works in the same teardown path. The pending_rx queue is still purged after the work has been cancelled and conn->lock has been acquired.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 07/20/2026
This vulnerability represents a critical deadlock condition in the Linux kernel's Bluetooth L2CAP implementation that arises from improper lock ordering during connection teardown operations. The flaw occurs when the l2cap_conn_del() function attempts to cancel pending work items before acquiring the connection lock, creating a circular dependency scenario that can lead to system hangs and denial of service conditions. The vulnerability is classified under CWE-253 as an "Error in Locking" and specifically manifests as a deadlock condition that violates fundamental concurrency control principles.
The technical flaw stems from the improper sequence of operations within the Bluetooth L2CAP connection deletion pathway where the kernel attempts to cancel work items using cancel_work_sync() while holding the conn->lock, but the worker function process_pending_rx() also attempts to acquire the same lock, creating a classic circular dependency. Static analysis tools identified this pattern as a potential deadlock hazard, and manual review confirmed that the existing codebase lacks proper ordering of lock acquisition relative to work cancellation operations. The lockdep subsystem detected this issue through its internal dependency tracking mechanism, which identified the problematic call chain involving process_pending_rx, l2cap_conn_del, and the mutex_lock operation.
The operational impact of this vulnerability is severe as it can cause complete system hangs when Bluetooth connections are being torn down, particularly affecting devices that rely heavily on Bluetooth connectivity such as smartphones, laptops, and IoT devices. An attacker could potentially exploit this weakness by triggering multiple concurrent Bluetooth connection attempts followed by rapid teardown operations, leading to denial of service conditions where the system becomes unresponsive to further Bluetooth operations. This vulnerability also demonstrates a failure in the kernel's lock ordering discipline, which is a fundamental requirement for maintaining system stability in concurrent environments and aligns with ATT&CK technique T1499.002 related to network disruption through resource exhaustion.
The fix implemented addresses this issue by reordering the operations within l2cap_conn_del() to cancel pending_rx_work before acquiring conn->lock, establishing a consistent lock-before-drain ordering pattern that matches existing practices for other delayed work items in the same teardown path. This approach ensures that all pending work items are flushed before any locks are acquired, preventing the circular dependency scenario. The solution maintains the existing functionality while ensuring proper resource cleanup through careful ordering of operations, where the pending_rx queue is still properly purged after work cancellation and lock acquisition, preserving system integrity while eliminating the deadlock condition. This fix aligns with kernel security best practices for concurrent programming and demonstrates the importance of maintaining consistent lock ordering principles throughout complex subsystems.