CVE-2026-64377 Affects Qualcomm Linux, Not Windows

The NVD page supplied with the report was unavailable behind a 502 Bad Gateway error on August 11, preventing a live check of its current scoring, affected-product mapping, or references. The primary Linux kernel patch and Debian’s security tracker independently confirm the underlying defect and the upstream fix: removing one

call from the CPU-frequency driver’s teardown path.

The more important finding is that this is a narrow driver-lifecycle flaw being cataloged as a CVE, not evidence of a remotely reachable, unauthenticated compromise. Some automated vulnerability feeds have assigned eye-catching “critical” labels and network-style CVSS vectors, but the published kernel record does not establish a remote exploit path. The actual trigger sits in removal or teardown of a Qualcomm CPU-frequency driver instance—an operational path that requires the affected driver to be present, bound to compatible hardware, and taken through its cleanup sequence.

The faulty free occurs during Qualcomm CPU-frequency teardown​

The affected component is

, which supports hardware-controlled CPU frequency scaling on certain Qualcomm SoCs. CPU-frequency code, generally called cpufreq, manages processor performance states; this particular driver exposes Qualcomm hardware frequency domains to the Linux kernel.

Guangshuo Li’s patch, posted to the Linux kernel mailing lists on May 2, identifies an ownership error in the driver. During probe, the driver allocates

using

, the kernel’s device-managed allocation mechanism. Device-managed memory is released automatically when the platform device is detached, so its ownership remains with the device resource manager rather than with an individual CPU policy teardown callback.

Each CPU frequency domain stores a pointer into that allocated array in

. But when a policy exits,

had been calling

on that pointer. That is wrong for two separate reasons.

For the first domain, the pointer can refer to the beginning of the device-managed allocation. Freeing it manually leaves the device resource manager holding an active cleanup record for already-freed memory. When the platform device is later detached, the resource manager may free it again: the double free named by CVE-2026-64377.

For later domains, the pointer can refer to an element inside the array rather than the allocation’s start address. Passing such an interior pointer to

is invalid in its own right. That is more than a bookkeeping concern; kernel allocators expect the original allocation address, and corrupted teardown paths can produce crashes or memory-corruption symptoms that are difficult to reproduce.

The fix is a one-line deletion. The CPU-policy exit path still releases its separately allocated frequency table and performs other cleanup, but it stops freeing

. Device resource management releases the underlying array once, at the appropriate point in device removal.

Viresh Kumar, the cpufreq maintainer, replied on May 5 that the patch had been applied. A review by Qualcomm engineer Zhongqiu Han explicitly agreed with the ownership analysis, noting that the per-policy pointer can point to a non-base array element and that dropping the

is the correct repair.

The patch history shows why version-based scanning matters​

The bug’s history is more complicated than the CVE wording alone suggests. The patch cites commit

, “cpufreq: qcom-hw: Allocate qcom_cpufreq_data during probe,” as the change that set up the bad ownership relationship. That work dates to late 2022, when the driver was reworked so its data could be allocated at device probe time rather than individually during CPU-policy initialization.

But an earlier stable-kernel fix from March 2023 had already dealt with closely related teardown errors in the same driver. That patch, commit

, removed duplicate I/O unmapping and resource-release work after the allocation and I/O mappings became device-managed. Its diff also removed a

from that older cleanup path.

In other words, CVE-2026-64377 should not be read as “every kernel descended from the 2022 refactor is exposed.” The code has moved, fixes have been backported selectively, and downstream distributions carry different combinations of driver changes. The 2026 fix addresses a later version of the cleanup path in which the invalid

remained or reappeared.

Debian’s tracker illustrates the consequence. It lists Debian bullseye and bookworm as not affected because the vulnerable code is absent from their packaged kernels. It marks Debian trixie’s

package as vulnerable and identifies

as fixed. Debian unstable moved from vulnerable

to fixed

. The upstream commit containing the correction is

, and Debian identifies it as present in Linux

.

That is the actionable lesson for Linux fleet owners: do not classify exposure from a major kernel number alone. A 6.12 kernel can be fixed or vulnerable depending on the distributor’s exact package revision and backport set. Checking the installed vendor kernel package, its changelog, and whether it includes the upstream correction is more reliable than treating “6.12” as a security verdict.

A “critical” label overstates what the public record demonstrates​

The public patch establishes a legitimate kernel memory-management defect. It does not document exploitation, a malicious input vector, a user-to-kernel escalation route, or a remotely triggerable condition. The issue was found by a static-analysis tool under development, according to Li’s patch submission, rather than disclosed with a proof of concept or a crash report from a hostile workload.

That distinction deserves attention because Tenable’s entry for the CVE labels it critical and presents a CVSS 3.0 vector that implies network reachability without privileges or user interaction. Tenable’s own page also says its check is package-based and may identify vendor-indicated unpatched packages. Its severity label is therefore not evidence that this particular driver flaw can be reached over the network.

A double free in kernel space can certainly be security-relevant. Depending on allocator behavior, surrounding code, and how reliably an attacker can drive the vulnerable teardown path, it could cause a system crash or, in a stronger case, become a memory-corruption primitive. But none of that has been demonstrated in the CVE description, kernel discussion, or the distributor status data reviewed here.

Administrators should patch affected systems because kernel cleanup defects are not harmless. They should not, however, turn a narrow Qualcomm cpufreq driver fix into an emergency response for unrelated Linux hosts or a Windows incident.

Windows, WSL, and Windows on Arm are separate from this CVE​

CVE-2026-64377 affects Linux kernel source code, specifically Qualcomm’s Linux CPU-frequency hardware driver. It does not affect the Windows scheduler, Windows power-management stack, Qualcomm Windows drivers, or the Windows 11 kernel. Microsoft has not issued a corresponding advisory in the record reviewed for this report.

Windows Subsystem for Linux needs slightly more careful wording. WSL 2 runs a real Linux kernel in a managed virtual machine, but a WSL distribution running on a conventional Windows PC does not normally own physical Qualcomm CPU frequency hardware or bind this platform driver. The vulnerable path is tied to the Linux kernel’s handling of an actual compatible Qualcomm platform device, not to ordinary Linux user-space software running under WSL.

The edge case is a custom Linux kernel or appliance image running directly on supported Qualcomm ARM hardware. That includes engineering builds, embedded products, ARM servers, and distributions that package the driver and bind it to relevant hardware. Those operators should follow their distribution’s kernel advisory rather than waiting for a Windows update that will never arrive.

The publication date and NVD record need cleanup​

There is a record inconsistency worth preserving for anyone building compliance timelines. The supplied NVD capture says the CVE was published on August 11, 2026, at 01:02 Pacific time, but Debian’s security tracker, Spain’s INCIBE advisory index, and Tenable’s plugin metadata all list July 25, 2026 as the publication date. The NVD service was returning a Cloudflare 502 error when checked on August 11, so its metadata could not be independently re-read.

This looks more like delayed NVD ingestion or a record timestamp difference than a dispute about the vulnerability itself. The kernel patch was public in May, accepted by the cpufreq maintainer days later, and the corrected code has reached both upstream and downstream packages. Still, asset-management teams should use the distribution package’s fixed version and the upstream commit—not an NVD page timestamp—as the basis for remediation evidence.

For Debian trixie users, the concrete fixed package is

; for Debian unstable, it is

. Other distributions should install the latest vendor-supported kernel containing commit

or an explicitly documented backport. Windows-only systems require no action for CVE-2026-64377.