CVE-2026-64404

What it actually does

This is a race condition in the Linux kernel Bluetooth ISO socket handling path. The vulnerable function temporarily releases a socket lock while resolving a Bluetooth HCI route, then reacquires the lock and dereferences iso_pi(sk)->conn->hcon without confirming that the connection object still exists. If a Bluetooth ISO connection teardown occurs during that unlocked window, iso_pi(sk)->conn or its hcon member can be cleared, leading to a NULL pointer dereference in kernel context. The most likely technical outcome is a kernel oops or system crash, resulting in local or proximity-triggered denial of service on systems with the affected Bluetooth ISO functionality enabled.

Why it matters to the business

Successful exploitation can crash affected Linux systems or disrupt Bluetooth-dependent services, causing availability loss for workstations, embedded Linux devices, kiosks, IoT/edge systems, or servers that expose Bluetooth functionality. The current public risk appears limited: the issue is not listed in CISA KEV, is not known to be used in ransomware campaigns, has low EPSS probability, and has no reported mature exploit. However, organizations with Linux systems that rely on Bluetooth Low Energy audio, broadcast audio, or controller-driven Bluetooth workflows should treat this as an availability risk and patch during the next appropriate kernel maintenance cycle.

How an attack unfolds

An attacker or local process causes the system to enter the Bluetooth ISO PA-sync broadcast sink receive path, which reaches iso_sock_recvmsg() and then iso_conn_big_sync(). During that operation, the kernel drops the socket lock to call hci_get_route(). In the short interval before the lock is reacquired, a Bluetooth controller event or teardown path can delete the ISO connection and clear the socket's connection pointer. When iso_conn_big_sync() resumes, the vulnerable kernel dereferences the stale or NULL connection pointer without revalidation, triggering a NULL pointer dereference in kernel space. In practical terms, exploitation is expected to require Bluetooth ISO support, a reachable Bluetooth/controller state that can trigger teardown timing, and the ability to exercise the relevant socket path; the expected impact is denial of service rather than data theft or code execution.

How to fix it

Upgrade to a Linux kernel version that includes the upstream fix for the Bluetooth ISO iso_conn_big_sync() revalidation bug. If using a distribution kernel, install the vendor-supplied kernel security update rather than attempting to backport manually. Because no exact affected product list or fixed package versions were provided, verify remediation through the Linux distribution's security advisories and kernel changelog for the patch that revalidates iso_pi(sk)->conn and conn->hcon after reacquiring the socket lock in iso_conn_big_sync(). Where immediate patching is not possible, reduce exposure by disabling Bluetooth on systems that do not require it, blocking or removing Bluetooth adapters, unloading Bluetooth-related kernel modules where operationally safe, and limiting local user access to Bluetooth socket capabilities according to distribution policy.

How to confirm the fix worked

Confirm the running kernel includes the fix by checking the installed kernel package version against the relevant distribution advisory or by verifying that the kernel source contains the added revalidation of iso_pi(sk)->conn and its hcon member after the lock is reacquired in net/bluetooth/iso.c. Confirm exposure reduction by verifying Bluetooth is disabled or unavailable on systems that do not need it. On Linux hosts, useful checks include reviewing the running kernel version with uname -a, installed kernel package metadata through the platform package manager, loaded Bluetooth modules with lsmod, Bluetooth adapter state with bluetoothctl or rfkill, and kernel logs for absence of recurring Bluetooth ISO oops traces after remediation.

Typical attack path

1. Identify a Linux system with Bluetooth enabled and kernel support for Bluetooth ISO sockets.
2. Create or induce a Bluetooth ISO PA-sync broadcast sink socket state that reaches the deferred setup receive path.
3. Trigger iso_sock_recvmsg(), causing execution to enter iso_conn_big_sync().
4. Race the lock drop in iso_conn_big_sync() with a Bluetooth ISO connection teardown or controller event that clears iso_pi(sk)->conn or conn->hcon.
5. Cause the kernel to dereference the now-NULL connection pointer.
6. Observe a kernel oops, Bluetooth subsystem failure, or full system crash/reboot.

How to detect it

To determine whether this issue may have already been triggered, review host kernel logs, persistent journal entries, crash dumps, and system reboot records for Bluetooth ISO-related kernel oops events. Relevant log sources include dmesg output, /var/log/kern.log, /var/log/messages, /var/log/syslog, systemd-journald kernel logs, kdump/vmcore artifacts, pstore/ramoops records on embedded systems, and EDR telemetry that captures kernel panic or unexpected reboot events. Focus on crashes that mention NULL pointer dereference, general protection fault, kernel oops, or panic with stack frames involving iso_conn_big_sync(), iso_sock_recvmsg(), iso_disconn_cfm(), iso_conn_del(), iso_chan_del(), or net/bluetooth/iso.c. Also correlate crashes with Bluetooth controller disconnect events, Bluetooth service activity, HCI errors, or nearby testing of Bluetooth LE audio/broadcast functionality. There are no known threat actors or public exploitation campaigns associated with this vulnerability at this time, so detection should focus on crash forensics and recurrence patterns rather than network indicators.

• iso_conn_big_sync
• iso_sock_recvmsg
• iso_disconn_cfm
• iso_conn_del
• iso_chan_del
• net/bluetooth/iso.c
• Bluetooth: ISO
• BUG: kernel NULL pointer dereference
• Oops: 0000
• Kernel panic - not syncing
• Unable to handle kernel NULL pointer dereference
• general protection fault
• Bluetooth: hci
• /var/log/kern.log
• /var/log/messages
• /var/log/syslog
• /sys/fs/pstore
• /var/crash
• vmcore
• kdump

What your security team should do

• Inventory Linux systems with Bluetooth enabled, prioritizing laptops, embedded devices, kiosks, IoT/edge appliances, and systems using Bluetooth LE audio or broadcast audio features.
• Apply vendor kernel updates that include the Bluetooth ISO fix during the next maintenance window; prioritize systems where Bluetooth is enabled and locally or physically accessible.
• Disable Bluetooth on systems where it is not operationally required, especially production servers and unattended devices.
• Monitor kernel logs for Bluetooth ISO-related oops or NULL pointer dereference traces, particularly references to iso_conn_big_sync(), iso_sock_recvmsg(), iso_disconn_cfm(), iso_conn_del(), or iso_chan_del().
• Treat unexpected crashes on Bluetooth-enabled Linux systems as potentially relevant until kernel logs or crash dumps rule out this bug.
• Because there is no KEV listing, no known ransomware use, low EPSS, and no mature public exploit, prioritize based on Bluetooth exposure and availability requirements rather than emergency internet-facing patch criteria.