A flaw in the Linux kernel Bluetooth L2CAP subsystem reveals that the function l2cap_conn_del() acquires the connection lock and then attempts to cancel a pending receive work queue while still holding the lock. However, the worker function process_pending_rx() also locks the same mutex. This ordering difference can create a circular lock dependency that leads to a deadlock during socket teardown, potentially locking up the kernel and causing a system hang.

This defect affects all Linux kernel binaries that include the buggy Bluetooth L2CAP code path, regardless of vendor. No specific kernel version numbers are listed; the problem exists in any build prior to the patch that reorders the cancellation of pending_rx_work to occur before acquiring conn->lock.

Based on the description, it is inferred that the attack vector requires a local user context capable of creating and destroying Bluetooth L2CAP connections via socket APIs. It has a CVSS score of 8.8, indicating high severity. The vulnerability is not catalogued in CISA KEV and has an EPSS score in the <1% range, indicating minimal public exploitation data. An attacker could potentially exploit the deadlock to cause a denial of service by repeatedly creating and destroying sockets until the kernel hangs. Because both cancellation of pending_rx_work and worker lock acquisition must occur, the risk level is moderate to low, but the impact is catastrophic if triggered.