The flaw arises from a reversed lock ordering in the Bluetooth L2CAP cleanup_listen function. While holding the parent socket lock, the code attempts to remove a channel with a different lock order, which can trigger a kernel deadlock. The resulting hang would disable Bluetooth services and could stall the entire system, manifesting as a denial‑of‑service. The incident is classified as CWE‑413, a classic lock‑ordering defect.

All Linux kernel releases that ship the legacy L2CAP cleanup_listen path are affected, as indicated by the broad Linux kernel CPE. Because the vulnerability description does not narrow the range, every current distribution that enables Bluetooth and exposes the default L2CAP implementation is at risk until the patch is applied.

The EPSS score of less than 1% suggests that successful exploitation is unlikely, and the vulnerability is not listed in CISA’s KEV catalog. No explicit attack vector is disclosed; however, it is reasonable to infer that an attacker could trigger the flaw by manipulating the Bluetooth stack, such as by sending malformed L2CAP packets or initiating connections that exercise cleanup_listen. Given the moderate CVSS of 5.5, the potential impact is limited to service disruption rather than data corruption or privilege escalation.