]> git.ipfire.org Git - thirdparty/kernel/linux.git/commit
cpufreq: qcom-cpufreq-hw: Fix possible double free
authorGuangshuo Li <lgs201920130244@gmail.com>
Fri, 1 May 2026 19:00:05 +0000 (03:00 +0800)
committerViresh Kumar <viresh.kumar@linaro.org>
Tue, 5 May 2026 05:07:00 +0000 (10:37 +0530)
commitbcb8889c4981fdde42d4fd2c29a77d510fe21da2
tree54fa1b046fd7dbf944be04fe56a9fa3cef9d95ad
parent88e8df5904007ea53232237acf9ad02aeb992ece
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.

Fixes: 054a3ef683a1 ("cpufreq: qcom-hw: Allocate qcom_cpufreq_data during probe")
Cc: stable@vger.kernel.org
Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com>
Reviewed-by: Zhongqiu Han <zhongqiu.han@oss.qualcomm.com>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
drivers/cpufreq/qcom-cpufreq-hw.c