CVE-2026-64128

What it actually does

This is a Linux kernel Bluetooth ISO receive-path denial-of-service flaw. Bluetooth ISO packets are fragmented using packet-boundary markers such as START, CONT, END, and SINGLE. The vulnerable ISO_END handling path assumes an ISO_START packet has already initialized receive state. If an ISO_END packet is received first on a fresh ISO connection, the kernel attempts to append data to a NULL socket buffer, causing a NULL pointer dereference and kernel oops. Depending on kernel configuration and system policy, this can crash the Bluetooth stack, destabilize the host, or panic/reboot the system. The BIS broadcast case is notable because receivers can synchronize to a broadcaster without pairing, so an attacker may not need prior trust with the target device.

Why it matters to the business

Successful exploitation can interrupt systems that rely on Bluetooth audio or Bluetooth Low Energy ISO functionality, including devices using LE Audio broadcast or isochronous streams. The most likely consequence is local service disruption or device instability rather than data theft. Because exploitation requires Bluetooth radio proximity or control of a Bluetooth broadcaster in range, broad internet-scale exploitation is unlikely; the current EPSS score is low and the issue is not listed in CISA KEV. However, organizations with Linux-based endpoints, embedded devices, kiosks, industrial systems, vehicles, medical devices, or consumer products that keep Bluetooth enabled in public or semi-public spaces should treat this as a reliability and availability risk.

How an attack unfolds

An attacker positions a malicious Bluetooth-capable device within radio range of a vulnerable Linux system with Bluetooth ISO support enabled. The attacker initiates or influences an ISO/BIS receive scenario and sends a malformed packet sequence where an ISO_END fragment is transmitted before any corresponding ISO_START fragment. In the vulnerable kernel receive path, ISO_CONT validates that receive state exists before using it, but ISO_END does not. The kernel therefore calls into buffer handling with conn->rx_skb still NULL and conn->rx_len still zero, resulting in a NULL pointer dereference in the Bluetooth ISO receive path. The immediate observable result is a kernel oops, Bluetooth subsystem failure, system instability, or a full crash/reboot depending on panic-on-oops and distribution settings. No evidence is provided that this vulnerability enables code execution or privilege escalation.

How to fix it

Apply a Linux kernel update that includes the Bluetooth ISO fix to drop ISO_END frames received without a prior ISO_START. Because no exact affected product list or fixed package versions were provided, remediation should be based on the relevant Linux distribution, device vendor, or kernel maintenance branch advisory. Prioritize updates for systems with Bluetooth enabled, systems exposed to untrusted physical environments, and products using LE Audio, BIS, or ISO features. Where immediate patching is not possible, reduce exposure by disabling Bluetooth, disabling Bluetooth services at boot, blocking use of untrusted Bluetooth peripherals, turning off Bluetooth discoverability, or restricting affected devices from public areas where an attacker could get within radio range. For embedded or appliance environments, obtain vendor firmware containing the upstream kernel fix and validate that the running kernel includes the ISO_END guard in the Bluetooth ISO receive path.

How to confirm the fix worked

Confirm that the running kernel version or vendor firmware build includes the Bluetooth ISO patch for dropping ISO_END frames when no ISO_START has initialized receive state. On Linux systems, verify the installed and running kernel versions after patching, not just the package version available on disk. Validate that Bluetooth can be disabled where it is not required and that the disabled state persists after reboot. For engineering validation, use a controlled lab with Bluetooth test equipment to send an ISO_END-first sequence to a patched system and confirm the packet is logged/dropped without kernel oops, panic, Bluetooth daemon failure, or system reboot. Review distribution or vendor advisories for backported fixes because the same source fix may appear under different kernel version numbers across maintained branches.

Typical attack path

1. Attacker identifies a Linux-based target with Bluetooth enabled and ISO/BIS functionality reachable over radio range.
2. Attacker uses a Bluetooth controller or software-defined Bluetooth tooling capable of crafting or influencing ISO packet-boundary flags.
3. Attacker establishes or abuses an ISO/BIS receive context, potentially as an unauthenticated broadcaster in BIS scenarios.
4. Attacker sends an ISO_END packet as the first fragment instead of sending a valid ISO_START first.
5. The vulnerable Linux kernel dereferences a NULL receive socket buffer in the ISO_END handling path.
6. The target logs a kernel oops and may lose Bluetooth functionality, become unstable, or reboot/panic.

How to detect it

Look for evidence of kernel crashes or Bluetooth subsystem failures occurring while Bluetooth was enabled or while the device was near untrusted Bluetooth activity. Relevant sources include kernel ring buffer output, system journal, syslog, crash dumps, kdump/vmcore records, watchdog reset logs, Bluetooth daemon logs, and endpoint availability/reboot telemetry. Search for NULL pointer dereference or kernel oops messages involving Bluetooth ISO receive handling, skb buffer operations, or functions such as iso_recv and skb_put. Also investigate unexplained reboots, panic events, Bluetooth controller resets, or bluetoothd restarts that coincide with nearby Bluetooth/BLE activity, LE Audio testing, or broadcast audio use. Because exploitation is radio-proximity based, network perimeter logs are generally not expected to show useful indicators. Absence of a crash log does not rule out exploitation if the device rebooted without persistent logging or if crash dumps were not configured.

• BUG: kernel NULL pointer dereference
• Oops: 0000
• kernel NULL pointer dereference
• Bluetooth: ISO
• iso_recv
• skb_put
• conn->rx_skb
• conn->rx_len
• bluetoothd
• Bluetooth: hci
• Kernel panic - not syncing
• panic_on_oops
• kdump
• vmcore

What your security team should do

• Inventory Linux systems and embedded products with Bluetooth enabled, especially those using LE Audio, BIS, or other ISO features.
• Patch kernels or vendor firmware once the relevant distribution or device-vendor fix is available; prioritize devices in public, shared, or physically accessible locations.
• Disable Bluetooth on systems where it is not operationally required, and enforce persistence of that configuration across reboots and image rebuilds.
• Monitor kernel logs for Bluetooth ISO receive-path crashes, NULL pointer dereferences, oops events, and unexpected reboots on Bluetooth-enabled systems.
• For high-availability or safety-sensitive Linux devices, evaluate panic-on-oops behavior and ensure watchdog/recovery behavior does not create unacceptable operational disruption.
• Add this issue to regression tests for Bluetooth-capable products: malformed ISO_END-before-ISO_START traffic should be dropped, not crash the host.
• Because EPSS is currently low, exploit maturity is reported as none, and the issue is not in KEV, treat this as a targeted proximity DoS risk rather than an internet-facing emergency, unless Bluetooth exposure is business-critical.