CVE-2026-64573: Patch Linux Qualcomm Bluetooth Flaw

The newly published CVE record from kernel.org says the bug was resolved upstream in July and added to NVD on August 5. The upstream Bluetooth commit was authored by Xiang Mei, reviewed by Qualcomm’s Bartosz Golaszewski, and accepted through the Bluetooth maintainers’ tree. Its impact is narrow in code location but relevant to laptops, embedded systems, routers, and appliances that use the Linux Qualcomm Bluetooth support stack.

For Windows users, this is not a Windows Bluetooth-stack vulnerability. The affected code is Linux kernel code, and the CVE points specifically to the

driver. A Windows 11 host does not load that driver. The relevant cases for WindowsForum readers are Linux dual-boot installations, Hyper-V or other Linux guests with passed-through hardware, embedded Linux devices, and managed fleets whose users happen to administer them from Windows. Ordinary WSL use is not the exposure described here: the flaw is reached when a Linux kernel brings up Qualcomm Bluetooth hardware and loads its firmware.

A signed-versus-unsigned check that turned a short record into a huge loop​

The defect sits in the parser for Qualcomm type-length-value firmware records, specifically the

path. The driver reads a length from the firmware header into a signed

, then used that value in a comparison against

, which is an unsigned

.

Before the fix, the loop effectively tested whether its current offset was less than:

The NVM record structure is 12 bytes before its variable-length data. If a supplied firmware record declared a length shorter than 12 bytes, C’s usual type conversions turned the signed length into an unsigned value before subtraction. Rather than producing a negative result and ending the loop, the subtraction wrapped to a very large positive number.

That made the parser believe there was plenty of data remaining. It could then read a 12-byte NVM record beyond the end of the

-allocated copy of the firmware file. Kernel AddressSanitizer caught a two-byte out-of-bounds read in

while Bluetooth was being powered on. The advisory also notes that handlers for certain EDL NVM tag IDs can write beyond that buffer after the invalid record has been interpreted.

The patch replaces the subtractive check with an additive one:

With non-negative values on both sides, a firmware record too short to contain even one NVM structure simply fails the condition and is skipped. It is a small change, but it closes the arithmetic failure at the point where the driver decides whether it is safe to dereference the record.

The trigger is firmware loading, not nearby Bluetooth traffic​

The CVE’s description and the upstream patch are clear about the object being parsed: a Qualcomm NVM firmware blob loaded by the kernel. The

path copies that blob into a writable

buffer, validates and potentially adjusts NVM tags, then downloads it to the Bluetooth controller.

That distinction narrows the immediate threat model. The public record does not show a nearby attacker sending a Bluetooth packet to trigger this bug, and it does not document an exploit using pairing, discovery, a malicious peripheral, or a Bluetooth radio advertisement. The vulnerable parser handles the firmware image selected during controller initialization.

In operational terms, an attacker would need a route to make the system load a malformed Qualcomm firmware file, or an administrator would need to deploy a corrupt or improperly packaged firmware image. That could arise from a compromised privileged update path, unsafe local firmware replacement, a custom image build, or a vendor appliance image that bundles the affected kernel and firmware. The demonstrated KASAN finding proves a kernel memory-safety error; it does not by itself establish reliable code execution or a remotely reachable attack chain.

That is why this deserves prompt maintenance rather than panic-driven Bluetooth shutdowns. Disabling Bluetooth can reduce exposure on an unpatched embedded deployment where firmware integrity is uncertain, but it is not a substitute for moving to a fixed kernel. Systems whose Bluetooth hardware is not driven by

are outside this specific flaw.

Qualcomm support is broader than a single laptop adapter​

The affected file is not the generic Bluetooth subsystem.

is the Qualcomm controller support library used alongside Qualcomm-specific transport drivers, including UART-based paths. The upstream header enumerates support for several Qualcomm families, including QCA Rome, WCN3950, WCN3988, WCN3990, WCN3991, QCA2066, QCA6390, WCN6750, WCN6855, and WCN7850.

That does not mean every system containing a Qualcomm Wi-Fi or Bluetooth-branded part is exposed. It means the host must be booting an affected Linux kernel, have the relevant Bluetooth support enabled, and traverse the NVM firmware-loading path. A Qualcomm wireless card under a different operating system driver is not enough.

Administrators can begin with a basic check:

uname -r
modinfo btqca
dmesg | grep -Ei 'qca|bluetooth'

establishes whether the driver is available in the installed kernel; it does not prove that the machine is actively using it. Kernel logs during boot or Bluetooth initialization are more useful for identifying an actual Qualcomm firmware load. On systems that expose their kernel configuration, checking for

can help identify whether the driver was built into the kernel or made available as a module.

Do not rely solely on a device manager label or the presence of a

firmware directory. Those are clues for inventory, not proof that this vulnerable code executes on that device.

NVD’s affected-version data currently contradicts itself​

The most important reporting issue is in the CVE data itself. NVD has no CVSS score, no CVSS vector, and no CWE assignment for CVE-2026-64573 as of August 9, 2026. More significantly, its version data contains two incompatible interpretations of the vulnerable range.

One part of the kernel.org-provided affected record lists these ranges as affected:

• Linux 5.15.159 through versions before 5.16.
• Linux 6.1.91 through versions before 6.2.
• Linux 6.6.31 through versions before 6.6.148.
• Linux 6.8.10 through versions before 6.9.

But another portion of the same NVD record says versions before Linux 6.9 are unaffected, while separately marking fixed maintenance releases. Those statements cannot both be used as a clean version test. The five stable-tree patch references attached to the CVE also show that maintainers backported the correction beyond one current development line.

For administrators, the practical conclusion is straightforward: do not interpret “pre-6.9 unaffected” as an all-clear. If a distribution kernel is derived from the explicitly listed older branches, confirm the downstream package contains the backport. Distribution version strings often differ from upstream Linux version numbers, and enterprise vendors commonly backport security patches without rebasing the entire kernel.

The CVE record identifies these upstream fixed baselines:

The older 5.15, 6.1, and 6.8 references make downstream verification particularly important. Those branches may be end-of-life upstream or maintained only through vendor policies, and the public CVE data does not present a single unambiguous fixed point for each one. A supported distribution’s security advisory or package changelog is the authoritative answer for its packaged kernel.

Patch the kernel and preserve firmware provenance​

The fix is entirely in the kernel parser. Updating

alone does not correct it, because a valid current Qualcomm firmware image does not remove the unsafe length calculation in the old driver. Conversely, replacing the kernel without controlling who can alter firmware files leaves a sensitive firmware-loading path exposed to privileged tampering, even though this particular arithmetic bug is gone.

For managed Linux systems, the response should be routine:

• Update to the vendor kernel package that incorporates the btqca NVM parser fix, then reboot into that kernel.
• Confirm the running kernel after restart rather than assuming a package installation changed the active boot entry.
• Check custom kernel builds and appliance images against the upstream patch, especially if they carry Qualcomm Bluetooth support.
• Restrict modification of firmware directories and avoid unverified board-vendor firmware bundles or ad hoc replacements.
• Track the NVD record for a CVSS assessment, but do not wait for a score before applying an available kernel update.

CVE-2026-64573 is a firmware-parser memory-safety defect in a privileged driver, triggered during a normal hardware bring-up path. The code fix is uncomplicated; the confusing part is the vulnerability database range. Patch to a vendor-confirmed fixed kernel, verify whether

is actually in use, and treat the current NVD pre-6.9 “unaffected” statement as a data-quality problem rather than a deployment decision.

References​

1. Primary source: NVD / Linux Kernel
   Published: August 9, 2026 at 8:42 AM UTC
   
   Loading…

   nvd.nist.gov
2. Security advisory: MSRC
   Published: August 9, 2026 at 8:42 AM UTC
   Original feed URL
   
   

   Security Update Guide - Microsoft Security Response Center

   msrc.microsoft.com
3. Related coverage: linux.googlesource.com
   
   Loading…

   linux.googlesource.com
4. Related coverage: kernel.googlesource.com
   
   pub/scm/linux/kernel/git/bluetooth/bluetooth-next - Git at Google
5. Related coverage: kernel.googlesource.com
   
   Loading…

   kernel.googlesource.com
6. Related coverage: codebrowser.dev
   
   

   linux/linux/drivers/bluetooth/ Source Tree

   Code browser for C, C++, Rust & Dart

   codebrowser.dev
7. Related coverage: codebrowser.dev
   
   

   btqca.h source code [linux/drivers/bluetooth/btqca.h] - Codebrowser

   Source code of linux/drivers/bluetooth/btqca.h linux v6.19-r on KDAB Codebrowser

   codebrowser.dev
8. Related coverage: gbmc.googlesource.com
   
   drivers/bluetooth/btqca.c - linux - Git at Google
9. Related coverage: android.googlesource.com
   
   drivers/bluetooth/btqca.c - kernel/common - Git at Google