A race condition in the Linux kernel Bluetooth SCO module allows the RX path to obtain a weak reference to an SCO connection that can be freed concurrently because the freeing occurs without acquiring the required device lock. This missing synchronization can result in a use‑after‑free where the kernel dereferences freed memory, triggering a kernel panic or KASAN error. The flaw stems from the hcon->sco_data back‑pointer being cleared without holding hdev->lock, while the RX path reads it under that lock.

All Linux kernel builds that include Bluetooth SCO support are affected until the patch that serialises the sco_conn lifetime is incorporated. Because the affected code is part of the standard kernel Bluetooth stack, any distribution shipping an unpatched kernel with SCO functionality—common in desktops, laptops, and embedded devices—should be considered vulnerable.

The CVSS score of 7.1 indicates a moderate‑to‑high severity vulnerability, while the EPSS score of < 1 % suggests a very low likelihood of exploitation under normal circumstances. The vulnerability is not listed in the CISA KEV catalog. Based on the description, it is inferred that exploitation requires a timing race between the RX path and a cleanup path, which is nontrivial and likely limited to privileged or local users capable of generating Bluetooth traffic. In the absence of a publicly known exploit, the risk remains moderate: a successful exploit would cause a kernel crash and loss of availability. The correct mitigation is to apply the vendor patch or to mask the vulnerable code path until the fix is available.