CVE-2026-53072

What it actually does

This vulnerability is a Linux kernel Bluetooth use-after-free condition in the HCI connection request handling path. When a Bluetooth protocol uses deferred setup via HCI_PROTO_DEFER, hci_conn_request_evt() can call hci_connect_cfm(conn) without holding the expected hdev->lock. If the Bluetooth connection object is deleted concurrently, the kernel may dereference freed memory. The most likely impact is a kernel crash or Bluetooth subsystem instability; depending on allocator state, timing, and hardening, kernel memory corruption may be possible, but no public exploit maturity is currently indicated.

Why it matters to the business

Systems with Bluetooth enabled may be exposed to denial-of-service risk from nearby attackers within Bluetooth radio range, potentially causing crashes, device instability, interrupted audio or headset workflows, and operational disruption on laptops, workstations, embedded Linux devices, kiosks, and other Bluetooth-capable Linux endpoints. The current EPSS score is low and the issue is not known to be in CISA KEV or ransomware campaigns, but kernel flaws should still be remediated through normal security update channels because impact can be high on exposed device fleets.

How an attack unfolds

An attacker would need the target system to have Bluetooth enabled and to be reachable over Bluetooth radio range. The attacker attempts to trigger the affected HCI connection request path, particularly where deferred setup is used by Bluetooth protocols such as SCO. By repeatedly initiating or manipulating connection requests while the target is creating and tearing down Bluetooth connection state, the attacker attempts to win a race where hci_connect_cfm() operates on a connection object that has already been freed. A successful trigger can corrupt kernel memory or crash the kernel, typically resulting in local system denial of service. There is no indication from the supplied intelligence that weaponized exploitation is public or that named threat actors are exploiting this issue.

How to fix it

Apply Linux kernel updates from the operating system or device vendor that include the upstream fix for the Bluetooth locking issue in hci_conn_request_evt(). If exact fixed package versions are not available, update to the latest vendor-supported kernel for each affected distribution or device line and reboot into the patched kernel. Where immediate patching is not possible, reduce exposure by disabling Bluetooth, blocking the Bluetooth service from starting, disabling discoverability/pairing, removing unnecessary Bluetooth hardware access, or enforcing endpoint configuration policies that keep Bluetooth off on systems that do not require it. Because the flaw is in kernel code, service restarts alone are not sufficient after patching; the system must run the fixed kernel.

How to confirm the fix worked

Confirm that each system is running a vendor kernel build released after the fix was incorporated, not merely that the package is installed. Validate with kernel package inventory, uname -a, distribution advisory checks, and reboot status. Confirm Bluetooth exposure by checking whether Bluetooth adapters are present and powered, whether bluetoothd is running, and whether systems are discoverable or accepting connections. On representative systems, verify that kernel logs no longer show crashes or KASAN reports involving hci_conn_request_evt(), hci_connect_cfm(), or Bluetooth HCI connection handling after applying the updated kernel. If Bluetooth is mitigated rather than patched, verify that adapters are disabled and cannot be re-enabled by unprivileged users or normal device policy drift.

Typical attack path

1. Identify a Linux target with Bluetooth enabled and discoverable or otherwise reachable over Bluetooth radio range.
2. Initiate Bluetooth connection attempts that reach the HCI connection request handling path.
3. Target protocol paths that use deferred setup, such as SCO-related connection handling.
4. Race connection establishment against connection teardown or deletion to cause the kernel to use a freed hci_conn object.
5. Trigger kernel memory corruption or a crash, causing Bluetooth subsystem failure or full system denial of service.

How to detect it

To assess possible prior exploitation, review kernel logs, system journals, crash dumps, and Bluetooth telemetry for evidence of crashes or memory-safety reports in the Bluetooth HCI connection request path. Relevant sources include journalctl -k, /var/log/kern.log, /var/log/messages, /var/crash, kdump/vmcore artifacts, apport or ABRT reports, KASAN/KFENCE reports, bluetoothd logs, audit records for Bluetooth service state changes, and btmon captures where available. Look for kernel oops, panic, general protection fault, slab corruption, or KASAN use-after-free reports that mention hci_conn_request_evt(), hci_connect_cfm(), hci_conn, SCO, or HCI connection request events. Correlate any crash timing with Bluetooth controller activity, unexpected pairing or connection attempts, repeated connect/disconnect activity, or physical proximity events. Absence of these artifacts does not prove non-exploitation because successful denial of service may leave limited logs if the kernel crashes before flushing buffers.

• KASAN: use-after-free
• BUG: KASAN
• KFENCE: use-after-free
• use-after-free in hci_conn_request_evt
• hci_conn_request_evt
• hci_connect_cfm
• Bluetooth: hci
• HCI Event: Connect Request
• SCO Connect Request
• general protection fault
• Unable to handle kernel NULL pointer dereference
• Unable to handle kernel paging request
• kernel BUG at net/bluetooth
• /var/log/kern.log
• /var/log/messages
• /var/crash
• /proc/vmcore

What your security team should do

• Prioritize patching Bluetooth-enabled Linux endpoints, mobile workstations, embedded devices, kiosks, conference-room systems, and other systems physically accessible to untrusted users.
• Deploy the latest vendor-supported Linux kernel containing the fix and ensure systems have rebooted into the updated kernel.
• Temporarily disable Bluetooth on systems that do not require it, especially in public or shared physical locations.
• Inventory Linux assets with active Bluetooth adapters and running Bluetooth services to determine practical exposure.
• Monitor kernel and system logs for Bluetooth-related crashes, KASAN use-after-free reports, and function names associated with this bug.
• Treat unexplained kernel panics on Bluetooth-enabled systems as potentially security-relevant when preceded by Bluetooth connection activity.
• Because EPSS is currently low and there is no KEV listing, handle through standard kernel security patch SLAs unless the environment has high Bluetooth exposure or safety/availability requirements.