CVE-2026-52918

What it actually does

This is a race condition in the Linux kernel Bluetooth socket implementation. The polling path can walk the Bluetooth accept queue while another thread tears down a child socket and removes it from the same queue, potentially dropping the final reference to that socket. Without synchronization, the polling code may access a socket object after it has been unlinked and freed. Depending on kernel configuration, timing, and memory layout, this can result in kernel memory corruption, a kernel crash, or a possible local privilege-escalation primitive. The fix serializes accept queue updates and polling with a dedicated lock and ensures temporary child socket references are safely taken before the queue lock is released.

Why it matters to the business

Systems with Bluetooth support enabled may be exposed to a kernel-level stability and security issue. The most likely operational impact is denial of service through a kernel crash, but because the flaw involves a race against object lifetime in kernel memory, organizations should treat it as potentially more serious on multi-user systems, workstations, kiosks, embedded Linux devices, and servers where untrusted users or workloads can access Bluetooth socket functionality. This CVE is not currently listed in CISA KEV, is not known to be used in ransomware campaigns, and has a low EPSS score of 0.00262, so broad active exploitation is not currently indicated; however, kernel race conditions can become more valuable once a reliable exploit is developed.

How an attack unfolds

An attacker would need a way to interact with the vulnerable Bluetooth socket code on a Linux system, typically through local code execution or another context capable of creating and polling Bluetooth sockets. The attacker would create Bluetooth socket activity that causes sockets to enter the accept queue, then concurrently trigger polling and teardown of child sockets so that one execution path walks the accept queue while another removes and releases the same socket object. If the timing is won, the polling path may operate on freed kernel memory. A simple exploit may only crash the kernel, while a more advanced exploit would attempt to reclaim the freed memory with attacker-influenced data and convert the use-after-free condition into controlled kernel memory corruption. There is no public exploit maturity indicated in the supplied data, and exploitation is expected to require precise local race timing rather than a straightforward remote request.

How to fix it

Apply a Linux kernel update that contains the Bluetooth accept queue serialization fix for CVE-2026-52918. Because no specific affected distributions or fixed package versions were provided, use the security advisory from the relevant Linux distribution, kernel vendor, appliance vendor, or embedded platform vendor to identify the corrected kernel build. Reboot into the updated kernel after installation; updating the package alone is insufficient if the system continues running the vulnerable kernel. Where immediate patching is not possible, reduce exposure by disabling Bluetooth if it is not required, preventing untrusted users or workloads from accessing Bluetooth socket functionality, unloading unused Bluetooth modules where operationally safe, and applying local access controls or sandboxing to limit the ability to create Bluetooth sockets. These mitigations reduce exploitability but do not replace the kernel fix.

How to confirm the fix worked

Confirm the running kernel, not just the installed package, has been updated to a vendor build that includes the fix. Validate with commands such as uname -a and the platform package manager, then compare against the distribution or vendor advisory for this CVE. After reboot, verify that the host is running the patched kernel version. If Bluetooth is intentionally disabled as a mitigation, confirm that Bluetooth services are stopped, Bluetooth modules are not loaded where feasible, and no unauthorized processes can create Bluetooth sockets. For source-based or custom kernels, confirm that the Bluetooth socket accept queue code includes locking around accept_q updates and polling and that bt_accept_dequeue() takes temporary child references under the queue lock before releasing it.

Typical attack path

1. Gain local code execution or another execution context capable of using Linux Bluetooth socket interfaces.
2. Confirm Bluetooth support and relevant kernel Bluetooth modules are present and usable.
3. Open Bluetooth sockets and drive accept-queue activity.
4. Run concurrent threads or processes that poll Bluetooth sockets while tearing down child sockets.
5. Attempt to trigger the race where bt_sock_poll() walks an accept queue entry as teardown unlinks and releases it.
6. Cause a kernel crash, or attempt to reclaim freed memory and shape it into a privilege-escalation primitive.
7. If privilege escalation succeeds, execute follow-on actions with elevated kernel or root-level privileges.

How to detect it

There is no reliable single log entry that proves exploitation, because successful kernel race exploitation may leave little evidence beyond crashes or abnormal kernel behavior. Review kernel logs, system journals, crash dumps, and endpoint telemetry for Bluetooth-related kernel faults, especially around polling, socket teardown, and accept queue handling. Useful sources include dmesg, journalctl -k, /var/log/kern.log, /var/log/messages, /var/crash, kdump/vmcore records, apport or ABRT crash reports, EDR process telemetry, and audit logs showing unusual local programs creating Bluetooth sockets. Look for kernel oops, panic, BUG, KASAN, KFENCE, or general protection fault messages that include Bluetooth socket functions such as bt_sock_poll() or bt_accept_dequeue(). Correlate these events with local user activity, recently executed binaries, high thread-count processes, fuzzing tools, suspicious temporary executables, or repeated crashes on systems where Bluetooth is enabled but not normally used. Absence of these artifacts does not rule out exploitation, especially if the system was not configured to retain kernel crash data.

• bt_sock_poll
• bt_accept_dequeue
• Bluetooth: serialize accept_q access
• accept_q
• KASAN: use-after-free
• BUG: KASAN
• KFENCE
• kernel BUG
• general protection fault
• Oops:
• Kernel panic
• Bluetooth socket
• /var/log/kern.log
• /var/log/messages
• /var/crash
• /proc/vmcore
• bluetooth.ko
• bt_sock

What your security team should do

• Inventory Linux systems with Bluetooth enabled or Bluetooth kernel modules available, prioritizing workstations, shared systems, embedded devices, kiosks, and systems that run untrusted local code.
• Track vendor advisories for the exact corrected kernel versions and deploy the patched kernel during the next appropriate maintenance window, with higher urgency for multi-user or physically accessible systems.
• Reboot systems after patching and verify the active kernel is the fixed version.
• Disable Bluetooth on systems where it is not business-critical, especially servers and hardened endpoints.
• Restrict local shell access, container escape opportunities, and untrusted workload execution on systems that cannot be patched promptly.
• Monitor kernel logs for Bluetooth-related crashes, use-after-free reports, KASAN warnings, or call traces involving bt_sock_poll, bt_accept_dequeue, or Bluetooth socket teardown.
• Because this vulnerability is not currently KEV-listed and has low EPSS, prioritize based on local exposure to Bluetooth and untrusted users rather than internet exposure alone.