Bug 2507265 (CVE-2026-64377) - CVE-2026-64377 kernel: cpufreq: qcom-cpufreq-hw: Fix possible double free
Summary: CVE-2026-64377 kernel: cpufreq: qcom-cpufreq-hw: Fix possible double free
Keywords:
Status: NEW
Alias: CVE-2026-64377
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Product Security DevOps Team
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2026-07-25 10:13 UTC by OSIDB Bzimport
Modified: 2026-07-27 07:12 UTC (History)
2 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed:
Embargoed:


Attachments (Terms of Use)

Description OSIDB Bzimport 2026-07-25 10:13:33 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.