CVE-2026-64539 Linux Bluetooth OOB Needs CAP_NET_ADMIN

The Linux kernel project’s fix prevents a three-byte, kernel-added Bluetooth Flags structure from pushing advertising data past a fixed 31-byte stack buffer. The defect was assigned CVE-2026-64539 in the Linux kernel CVE process on July 27, while the NVD record became visible later. At publication time on August 11, NVD’s public page was returning a Cloudflare 502 error, leaving administrators without an NVD severity score or its usual affected-version metadata. That outage is worth noting because a missing CVSS score is not evidence that the flaw is harmless—or that it is remotely exploitable.

The overflow is in Linux advertising setup, not Windows pairing​

The vulnerable function,

, assembles Bluetooth Low Energy advertising payloads. In the legacy path, that payload has a hard 31-byte limit. When the controller is LE-only, the kernel can automatically place a three-byte Flags advertising-data structure at the front of the packet to indicate that BR/EDR classic Bluetooth is unavailable.

The mistake was a mismatch between validation and construction. Linux accepted a full-length per-instance advertising payload when the caller supplied advertising flags of zero. Later, when advertising began, the kernel still added its own three-byte Flags structure and copied the previously accepted data without confirming that the combined result fit in the same 31-byte stack buffer.

In the maximum case, the operation attempts to place 34 bytes into a 31-byte buffer. Kernel AddressSanitizer caught the resulting stack out-of-bounds write in

, on a Bluetooth workqueue thread.

This is an important technical limit on the bug’s likely impact: the known condition is a small, bounded overwrite, not an arbitrary-length write. The advisory record describes a stack write past a 31-byte advertising buffer; it does not document a working privilege-escalation exploit, code execution, data disclosure, or a wireless attack chain. Those distinctions should govern response priority.

The original patch discussion on the Linux Kernel Mailing List makes the intended behavior clear. When the full advertisement cannot accommodate both the automatically generated Flags data and the user-provided payload, the kernel should preserve the user payload and omit the kernel-added Flags field rather than overrun memory. The final upstream change is small, but it closes the gap between the input-length checks and the data actually emitted.

A nearby Bluetooth device cannot trigger this by itself​

The most consequential omitted detail in short CVE summaries is the access requirement. The upstream commit and Debian Security Tracker both identify the vulnerable configuration as reachable by a local user holding CAP_NET_ADMIN who owns an LE-only controller and uses legacy advertising.

That rules out the common interpretation of a Bluetooth CVE: a hostile phone, headset, or nearby radio device scanning from across the room does not directly activate this flaw. The vulnerable path is used while configuring the local system’s own Bluetooth advertisements, not while parsing an advertisement received over the air.

On a conventional Linux workstation, an unprivileged desktop application normally does not receive

. BlueZ’s management operations and direct controller configuration are generally protected precisely because they alter network and radio state. The threat model becomes more relevant when a service, container, test harness, device-management application, or debugging environment has been deliberately granted that capability.

That still matters in infrastructure environments. A container with

is not fully equivalent to root on the host, but it has a substantially wider control surface than an ordinary application. If that workload can also access a passed-through Bluetooth adapter, it may be able to reach code that most server administrators assume is irrelevant. Bluetooth-equipped edge devices, kiosks, lab systems, industrial gateways, and Linux development hosts deserve a more careful review than headless servers with no Bluetooth hardware or kernel support.

The vulnerable logic dates back to the Linux 4.1-era work that added discoverable advertising flags. It persisted despite a later 2025 repair, commit

, that added bounds handling for other advertising structures in the same function. The current CVE exists because that earlier repair did not guard the final copy of per-instance advertising data. In other words, this is not a brand-new feature regression: it is a long-lived edge case uncovered in code that had already received a partial safety fix.

Fixed releases are arriving unevenly​

The upstream Bluetooth maintainer accepted the repair in June, and it later entered the mainline Linux tree as commit

, associated with Linux 7.2-rc1. Stable distribution coverage is not uniform, which is the operational issue administrators need to watch.

Debian’s Security Tracker currently lists its unstable branch as fixed in source package version

. It also lists Debian Trixie as fixed in

. At the same time, the tracker marks its currently listed Bullseye 5.10, Bookworm 6.1, and several other package lines as vulnerable.

Those package statuses do not mean every Linux 5.10 or 6.1 system worldwide is necessarily exposed in the same way. Enterprise distributions frequently backport individual patches without changing their apparent upstream kernel generation, while some vendors disable Bluetooth components or do not ship the relevant configuration. Conversely, a kernel version alone is not enough proof of safety if a vendor has not documented the backport.

Administrators should therefore verify the vendor’s advisory or changelog for CVE-2026-64539 or the upstream fix, rather than assuming a broad “kernel update” has included it. The relevant upstream commit title is “Bluetooth: eir: Fix stack OOB write when prepending the Flags AD,” which is the most useful string to search in vendor patch notes.

The NVD service disruption makes that vendor-first approach more important today. NVD is a valuable index, but it is not the primary record for Linux patch availability. The kernel commit, the Linux kernel CVE announcement, and a distribution’s own security tracker are the records that establish what code was changed and whether a packaged kernel carries it.

WSL 2 needs a configuration check, not a panic patch​

Windows itself does not use this Linux Bluetooth advertising code for its native Bluetooth stack. CVE-2026-64539 is not a Windows kernel vulnerability and is not addressed by a standard Windows cumulative update.

WSL 2 changes the analysis because it runs a Microsoft-maintained Linux kernel inside a lightweight Hyper-V virtual machine. Microsoft’s WSL kernel releases currently include both 6.6 and rolling 6.18 branches, and the company’s public release list does not identify CVE-2026-64539 by name. A WSL user should not assume that merely being on a newer numerical WSL kernel means this specific Bluetooth backport is present.

The default WSL 2 setup also does not normally hand a distribution the host’s internal Bluetooth controller. That limits exposure for ordinary developer installations. The calculation changes for users who have attached a USB Bluetooth adapter through USB/IP, built a custom WSL kernel, enabled Bluetooth tooling, or given a privileged workload access to the resulting controller.

For those environments, the immediate steps are straightforward:

• Run uname -r inside the WSL distribution or Linux guest to record the kernel actually in use, rather than relying on the distribution release name.
• Update WSL from an elevated Windows terminal with wsl --update, then restart its virtual machine with wsl --shutdown.
• Check whether a Bluetooth controller is visible inside the guest with bluetoothctl list or hciconfig -a, if those tools are installed.
• Review any container, systemd service, or device-management workload that has both CAP_NET_ADMIN and access to a Bluetooth adapter.
• Disable or detach Bluetooth pass-through where it is not needed until the kernel supplier confirms the fix.

The more mundane answer is often the right one: a WSL installation with no Bluetooth controller cannot use the affected advertising path. A Linux server with Bluetooth disabled is also outside the reachable configuration described by the upstream advisory.

Patch the privileged edge case, not the radio headline​

CVE-2026-64539 is a legitimate kernel memory-safety flaw, and its age shows why Bluetooth code should not be dismissed as “desktop-only” plumbing. But the available record does not support treating it as an unauthenticated nearby-device attack or a general Windows Bluetooth emergency.

The urgent population is smaller and clearer: Linux systems that expose an LE-only Bluetooth controller to locally privileged users or workloads, especially where

has been granted for application, container, test, or device-management purposes. Those administrators should install the vendor kernel update that carries the fix and confirm whether their Bluetooth pass-through setup makes the vulnerable path reachable.

For everyone else, the concrete consequence is a verification task rather than a rushed fleet-wide incident response: update the Linux kernel on the normal security cadence, keep WSL current, and avoid assigning Bluetooth hardware plus network-administration capability to workloads that do not require both.