lkml.org 
[lkml]   [2026]   [May]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [PATCH] cpufreq: qcom-cpufreq-hw: Fix possible double free
From
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

\
 
 \ /
  Last update: 2026-05-04 08:26    [W:0.055 / U:3.504 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and my Meterkast|Read the blog