CVE-2026-64377 in Linuxinfo

Summary

by MITRE • 07/25/2026

In the Linux kernel, the following vulnerability has been resolved:

cpufreq: qcom-cpufreq-hw: Fix possible double free

qcom_cpufreq.data is allocated with devm_kzalloc() in probe() as an array of per-domain data. qcom_cpufreq_hw_cpu_init() stores a pointer to one element of this array in policy->driver_data.

qcom_cpufreq_hw_cpu_exit() currently calls kfree() on policy->driver_data. This is not valid because the memory is devm-managed. For the first domain, this can free the devm-managed allocation while the devres entry is still active, leading to a possible double free when the platform device is later detached. For other domains, the pointer may refer to an element inside the array rather than the allocation base.

Remove the kfree(data) call and let devres release qcom_cpufreq.data.

This issue was found by a static analysis tool I am developing.

VulDB is the best source for vulnerability data and more expert information about this specific topic.

Analysis

by VulDB Data Team • 07/25/2026

The vulnerability described represents a critical memory management flaw in the Qualcomm cpufreq hardware driver within the Linux kernel, specifically affecting the qcom-cpufreq-hw subsystem. This issue stems from improper handling of device-managed memory allocation and deallocation patterns that can lead to severe system instability through double free conditions. The root cause lies in the incorrect use of devm_kzalloc for allocating per-domain data structures while simultaneously attempting manual deallocation through kfree() calls, creating a fundamental conflict in memory management semantics.

The technical flaw manifests when the qcom_cpufreq_hw_cpu_init function stores pointers to individual array elements within policy->driver_data, which are then processed by qcom_cpufreq_hw_cpu_exit during CPU hotplug operations. The devm_kzalloc function allocates memory that is automatically managed by the device resource management subsystem, meaning the kernel's devres framework handles deallocation when the device is detached. However, the current implementation attempts to manually free this memory through kfree(), which results in a double free scenario for the first domain where the base allocation is freed while devres entries remain active, and potentially invalid memory access patterns for subsequent domains where pointers reference internal array offsets rather than base addresses.

This vulnerability directly maps to CWE-415: Double Free and CWE-416: Use After Free, both of which are classified as critical memory safety issues in the Common Weakness Enumeration catalog. The operational impact extends beyond simple system crashes or hangs, potentially enabling privilege escalation or denial of service conditions that could compromise entire systems running affected kernel versions. Attackers could exploit this vulnerability through malicious device initialization sequences or by triggering specific CPU hotplug events that activate the flawed cleanup path. The static analysis tool mentioned in the description highlights the sophisticated nature of modern security research tools capable of identifying such subtle memory management race conditions.

The recommended mitigation strategy involves removing the erroneous kfree(data) call from qcom_cpufreq_hw_cpu_exit function entirely, allowing the device resource management framework to handle proper deallocation when the platform device is detached. This approach aligns with established kernel development practices for device-managed memory allocation and ensures compliance with the Linux kernel's devres subsystem semantics. The fix demonstrates adherence to security best practices outlined in the ATT&CK framework under T1068: Exploitation for Privilege Escalation, as it prevents potential exploitation through memory corruption vulnerabilities that could otherwise be leveraged for unauthorized system access or control. Systems should be updated to kernel versions containing this patch to eliminate the risk of exploitation and maintain overall system stability.

Responsible

Linux

Reservation

07/19/2026

Disclosure

07/25/2026

Moderation

accepted

CPE

ready

EPSS

0.00209

KEV

no

Activities

low

Sources

Are you interested in using VulDB?

Download the whitepaper to learn more about our service!