A deadlock can occur when the Bluetooth L2CAP connection teardown routine holds a lock while cancelling delayed work that also tries to acquire the same lock. If the work is already executing, the routine may deadlock, freezing the task that performed the deletion and potentially hanging dependent processes. The flaw results in a denial of service rather than a breach of confidentiality or integrity. The attack vector is inferred to involve an attacker capable of initiating a Bluetooth L2CAP connection deletion while the timers remain active, which can be achieved either remotely as a malicious Bluetooth client or locally by a user with sufficient privileges.

All Linux kernel installations that contain the L2CAP code before the referenced patch are affected. This includes any Linux distribution that has not yet applied the commit that moves the work cancellations outside the lock. The precise kernel versions are not listed, but the fix is present in patches traced by the Git commit links provided.

The exploitability is limited to contexts where an attacker can trigger an L2CAP connection delete while the related timers are active, which could be achieved through a malicious Bluetooth client or a local user with the ability to manage Bluetooth connections. Because the description does not explicitly state the attack vector, it is inferred that an attacker must be able to trigger L2CAP connection deletion while the timers are active, either remotely as a Bluetooth client or locally as a user with privileges. The CVSS score is 5.5 and the EPSS score is < 1%; the vulnerability is not listed in the CISA KEV catalog, indicating that it might not be actively exploited in the wild. Nonetheless, the potential for a service disruption warrants prompt remediation.