Messages in this thread |  | | Date | Mon, 4 May 2026 14:24:12 +0800 | | Subject | Re: [PATCH] cpufreq: qcom-cpufreq-hw: Fix possible double free | | From | 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
|  |