A race condition exists in the Linux kernel’s Bluetooth HCI driver when a device is being closed while socket writes to hci_send_acl, hci_send_sco, or hci_send_iso are in progress. The HCI send functions unconditionally queue work on tx_work, but the workqueue is already marked as draining during hci_dev_close_sync. The kernel therefore refuses to enqueue the work, prints a warning, and drops the queued work without sending the Bluetooth commands. The missing commands can interrupt Bluetooth communication, causing applications that depend on Bluetooth to fail or lose connectivity. The likely attack vector is a local scenario where an attacker is able to perform socket writes to a Bluetooth socket while a close operation is underway; this inference is drawn from the description of the concurrent send/close paths.

The flaw resides entirely in the Linux kernel and therefore affects every Linux distribution that ships a kernel without the hci_sched_tx fix. Any system running a kernel build prior to the commit that introduces the guard will be vulnerable, regardless of the vendor. Typical distributions such as Ubuntu, Debian, RHEL, CentOS, Fedora, SUSE, and others must verify that they have applied the latest kernel update that contains this change.

The EPSS score of less than 1% indicates a very low probability of exploitation, and the vulnerability is not listed in the CISA KEV catalog. No public exploitation is known. The CVSS score is 5.5 but the impact is limited to local denial of service for Bluetooth-related services rather than remote code execution or privilege escalation. The risk is considered moderate in environments where Bluetooth is critical, and risk diminishes if the kernel is patched or Bluetooth is disabled during shutdown.