The description indicates a race condition in sco_sock_timeout() that allows the kernel to acquire the same socket lock twice when a Bluetooth SCO socket is closed concurrently with a pending timeout. The double acquisition causes a deadlock, which can stall kernel threads, freeze the Bluetooth stack, and potentially lock up the entire system. Based on the description, this leads to a denial‑of‑service condition, as the system may become unresponsive, though no direct code execution or data disclosure is noted.

The description specifies that the patch moved disable_delayed_work_sync outside lock_sock, but it does not enumerate the affected kernel versions. Based on the description, any Linux kernel builds prior to that change are potentially vulnerable. Thus, deployments using those kernel versions are possibly affected, regardless of distribution.

The description does not provide an EPSS score or a KEV listing; thus we have no evidence of known widespread exploitation. The impact is limited to service interruption via a deadlock. There is no explicit statement of how an attacker could trigger the condition remotely, so this inference suggests that exploitation would require local control of Bluetooth SCO connections or manipulation of timing between socket close and timeout. Therefore, the risk is largely local or confined to environments where an attacker can inject Bluetooth traffic to trigger the race.