CVE-2026-63946

What it actually does

This is a Linux kernel use-after-free vulnerability in the Bluetooth ISO receive path. The vulnerable code reads a socket pointer from an ISO connection while holding a lock, releases the lock, and then continues using the socket without holding a reference. If another thread concurrently destroys the ISO socket, the kernel may dereference freed memory while checking socket state or queueing a received Bluetooth packet. Successful exploitation could allow an adjacent attacker with Bluetooth radio proximity to trigger memory corruption in kernel context, potentially causing denial of service, information disclosure, or privilege-impacting code execution depending on allocator state and exploit reliability.

Why it matters to the business

Systems with Bluetooth enabled and vulnerable Linux kernel versions may be exposed to attacks from nearby adversaries without requiring credentials or user interaction. The most likely operational impact is kernel instability or system crashes on laptops, workstations, embedded Linux devices, kiosks, IoT devices, and other Bluetooth-capable assets. Because the flaw is in kernel code and has a high CVSS score, organizations should prioritize patching Bluetooth-enabled systems even though public exploitation is not currently reported, EPSS is low, and the issue is not listed in CISA KEV.

How an attack unfolds

An attacker must be within Bluetooth range of a vulnerable Linux system with Bluetooth and ISO-related functionality reachable. The attacker sends crafted or timed Bluetooth ISO traffic while inducing or racing connection teardown behavior so that the kernel receive path obtains a socket pointer, drops the connection lock, and then another path frees that socket before it is used. The vulnerable kernel then accesses freed socket memory during state checks or packet queueing. In a simple attack this can crash the kernel; in a more advanced attack, the adversary would attempt heap grooming and timing control to reuse the freed memory with attacker-influenced data, turning the use-after-free into broader kernel memory corruption.

How to fix it

Upgrade the Linux kernel to a version that includes the Bluetooth ISO fix for iso_recv_frame using iso_sock_hold() / sock_hold() and balanced sock_put() handling. If vendor packages are used, apply the relevant distribution kernel update rather than attempting to backport manually. Where immediate patching is not possible, reduce exposure by disabling Bluetooth, blocking Bluetooth services not required for business operations, disabling affected ISO/Bluetooth audio features where feasible, or unloading/blocklisting Bluetooth kernel modules on systems that do not require Bluetooth. Prioritize laptops, user workstations, embedded systems, and appliances with Bluetooth enabled and physical proximity exposure.

How to confirm the fix worked

Confirm the running kernel includes the upstream or vendor fix for the Bluetooth ISO use-after-free in iso_recv_frame. Validate by checking installed kernel package versions against the relevant Linux distribution advisory or by confirming the source contains the corrected reference-handling pattern that takes a socket reference while holding the ISO connection lock and releases it on all exit paths. Operationally, verify Bluetooth exposure by checking whether Bluetooth is enabled, whether Bluetooth kernel modules are loaded, and whether the host can accept Bluetooth connections. After patching, reboot into the fixed kernel and confirm the active running kernel is the updated version, not only that the package is installed.

Typical attack path

1. Identify a nearby Linux device with Bluetooth enabled and reachable over radio proximity.
2. Establish or interact with a Bluetooth ISO connection path supported by the target kernel and hardware.
3. Send crafted Bluetooth ISO frames while causing rapid connection lifecycle changes or teardown behavior.
4. Trigger the race between iso_recv_frame() using the socket pointer and iso_sock_kill() freeing the same socket.
5. Cause kernel use-after-free during socket state access or receive-queue handling.
6. Leverage the resulting memory corruption for denial of service or, with advanced exploitation, attempt kernel-level compromise.

How to detect it

Look for evidence of kernel instability or memory corruption associated with Bluetooth ISO handling. Useful sources include system journal logs, kernel ring buffer output, crash dumps, endpoint telemetry, Bluetooth service logs, and fleet reboot/crash telemetry. Search for kernel oops, panic, KASAN, slab, or use-after-free messages referencing Bluetooth ISO functions such as iso_recv_frame, iso_sock_kill, sock_queue_rcv_skb, or sk_state. Also review timelines for unexpected reboots, Bluetooth connection attempts, repeated Bluetooth disconnect/connect events, and crashes occurring when unfamiliar Bluetooth devices were nearby. Absence of these artifacts does not prove non-exploitation, because a successful kernel exploit may leave minimal logs and a crash may erase volatile evidence.

• iso_recv_frame
• iso_sock_kill
• sock_queue_rcv_skb
• sk->sk_state
• Bluetooth: ISO
• use-after-free
• KASAN: use-after-free
• BUG: KASAN
• kernel BUG
• Oops:
• general protection fault
• slab-use-after-free
• Bluetooth
• btusb
• bluetoothd
• kernel panic

What your security team should do

• Inventory Linux systems with Bluetooth hardware or loaded Bluetooth kernel modules and prioritize those for remediation.
• Patch affected Linux kernels through vendor-supported updates and reboot systems into the fixed kernel.
• Temporarily disable Bluetooth on systems where it is not required, especially high-value workstations, shared devices, kiosks, and embedded Linux systems.
• Monitor kernel logs for Bluetooth ISO crashes, use-after-free warnings, kernel oops messages, or unexpected reboots on Bluetooth-enabled endpoints.
• Treat exploitation as local-proximity/adjacent-network risk: focus controls on physical access areas, unmanaged nearby devices, and systems in public or semi-public spaces.
• Because the CVE is not currently in KEV and has low EPSS, handle through accelerated patching for exposed Bluetooth assets rather than emergency internet-facing remediation.