[PATCH] cpufreq: qcom-cpufreq-hw: Fix possible double free

[PATCH] cpufreq: qcom-cpufreq-hw: Fix possible double free

[Guangshuo Li]

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>
---
 drivers/cpufreq/qcom-cpufreq-hw.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/cpufreq/qcom-cpufreq-hw.c b/drivers/cpufreq/qcom-cpufreq-hw.c
index ea9a20d27b8f..ef19faedbfec 100644
--- a/drivers/cpufreq/qcom-cpufreq-hw.c
+++ b/drivers/cpufreq/qcom-cpufreq-hw.c
@@ -578,7 +578,6 @@ static void qcom_cpufreq_hw_cpu_exit(struct cpufreq_policy *policy)
 	dev_pm_opp_of_cpumask_remove_table(policy->related_cpus);
 	qcom_cpufreq_hw_lmh_exit(data);
 	kfree(policy->freq_table);
-	kfree(data);
 }
 
 static void qcom_cpufreq_ready(struct cpufreq_policy *policy)
-- 
2.43.0

Re: [PATCH] cpufreq: qcom-cpufreq-hw: Fix possible double free

[Zhongqiu Han]

On 5/2/2026 3:00 AM, Guangshuo Li wrote:
> 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>


Hi Guangshuo,

Thanks for fixing this.

Yes, qcom_cpufreq.data is devm-managed and policy->driver_data
points into that per-domain array, so freeing it from ->exit() is
invalid (and for non-zero domains it can even be a non-base pointer).
Dropping kfree(data) is the correct fix.


Reviewed-by: Zhongqiu Han <zhongqiu.han@oss.qualcomm.com>


Regarding the sashiko.dev AI-generated review comments[1]: all four
issues raised are pre-existing possible problems in the driver and were
not introduced by this patch.

- The data->policy dangling pointer via the clock provider path
- The race window in qcom_cpufreq_hw_cpu_offline() between
   cancel_delayed_work_sync() and disable_irq_nosync()
- The unowned IRQ operations when request_threaded_irq() fails
- The freq_table/OPP leak on cpu_init() error paths

They are potentially valid observations worth addressing, but should be
handled as separate follow-up patches.

[1]https://sashiko.dev/#/patchset/20260501190005.504962-1-lgs201920130244%40gmail.com







> ---
>   drivers/cpufreq/qcom-cpufreq-hw.c | 1 -
>   1 file changed, 1 deletion(-)
> 
> diff --git a/drivers/cpufreq/qcom-cpufreq-hw.c b/drivers/cpufreq/qcom-cpufreq-hw.c
> index ea9a20d27b8f..ef19faedbfec 100644
> --- a/drivers/cpufreq/qcom-cpufreq-hw.c
> +++ b/drivers/cpufreq/qcom-cpufreq-hw.c
> @@ -578,7 +578,6 @@ static void qcom_cpufreq_hw_cpu_exit(struct cpufreq_policy *policy)
>   	dev_pm_opp_of_cpumask_remove_table(policy->related_cpus);
>   	qcom_cpufreq_hw_lmh_exit(data);
>   	kfree(policy->freq_table);
> -	kfree(data);
>   }
>   
>   static void qcom_cpufreq_ready(struct cpufreq_policy *policy)


-- 
Thx and BRs,
Zhongqiu Han

Re: [PATCH] cpufreq: qcom-cpufreq-hw: Fix possible double free

[Viresh Kumar]

On 02-05-26, 03:00, Guangshuo Li wrote:
> 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>
> ---
>  drivers/cpufreq/qcom-cpufreq-hw.c | 1 -
>  1 file changed, 1 deletion(-)

Applied. Thanks.

-- 
viresh