From: Zhongqiu Han <zhongqiu.han@oss.qualcomm.com>
To: lirongqing <lirongqing@baidu.com>,
"Rafael J . Wysocki" <rafael@kernel.org>,
Viresh Kumar <viresh.kumar@linaro.org>,
linux-pm@vger.kernel.org
Cc: zhongqiu.han@oss.qualcomm.com,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] cpufreq: acpi-cpufreq: Using cpufreq_for_each_entry() to iterate in extract_io()
Date: Wed, 12 Aug 2026 21:59:13 +0800 [thread overview]
Message-ID: <b375a4bb-2df2-4b9b-ba28-6ef153a89c70@oss.qualcomm.com> (raw)
In-Reply-To: <20260810061045.2397-3-lirongqing@baidu.com>
On 8/10/2026 2:10 PM, lirongqing wrote:
> From: Li RongQing <lirongqing@baidu.com>
>
> In extract_io(), the loop iterates up to perf->state_count. However,
> when building policy->freq_table in acpi_cpufreq_cpu_init(), duplicate
> frequency entries are skipped, making freq_table smaller than
> perf->state_count.
>
> Iterating perf->state_count times directly over policy->freq_table[i] can
> result in out-of-bounds array reads. Furthermore, policy->freq_table[i]
There is no out-of-bounds access. The array has "state_count + 1"
elements, so every index in "[0, state_count)" is inside the allocation.
right? The changelog looks like a memory-safety fix, which it is not,
and that wording alone would get the patch (mis)routed to stable and to
CVE bots.
> does not necessarily correspond to perf->states[i], as the original P-state
> index is stored in freq_table[entry].driver_data.
Yes, the real defect is the index space mismatch.
Might be good to note the side effects of it, AFAICT
freq_table[i] is not perf->states[i] once any _PSS entry has been
skipped. The function can therefore return a frequency belonging to a
different P-state, or 0 (zeroed tail entries), or CPUFREQ_TABLE_END
(~1u) when "i == valid_states", i.e. 0xfffffffe kHz reported
as a frequency. That last one is worth spelling out.
>
> Fix this by using cpufreq_for_each_entry() to iterate over
> policy->freq_table, similar to extract_msr().
>
Please add one Fixes tag here as well.
> Signed-off-by: Li RongQing <lirongqing@baidu.com>
> ---
> drivers/cpufreq/acpi-cpufreq.c | 9 ++++-----
> 1 file changed, 4 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/cpufreq/acpi-cpufreq.c b/drivers/cpufreq/acpi-cpufreq.c
> index 21639d9..87e4923 100644
> --- a/drivers/cpufreq/acpi-cpufreq.c
> +++ b/drivers/cpufreq/acpi-cpufreq.c
> @@ -196,15 +196,14 @@ static int check_amd_hwpstate_cpu(unsigned int cpuid)
> static unsigned extract_io(struct cpufreq_policy *policy, u32 value)
> {
> struct acpi_cpufreq_data *data = policy->driver_data;
> + struct cpufreq_frequency_table *pos;
> struct acpi_processor_performance *perf;
> - int i;
>
> perf = to_perf_data(data);
>
> - for (i = 0; i < perf->state_count; i++) {
> - if (value == perf->states[i].status)
> - return policy->freq_table[i].frequency;
> - }
> + cpufreq_for_each_entry(pos, policy->freq_table)
> + if (value == perf->states[pos->driver_data].status)
> + return pos->frequency;
> return 0;
> }
One more potential same issue is in func get_cur_freq_on_cpu()
cached_freq = policy->freq_table[to_perf_data(data)->state].frequency;
It is better to fix it as well.
For v2, please use ./scripts/get_maintainer.pl to generate the CC list
so linux-kernel@vger.kernel.org doesn't get missed. Thanks
>
--
Thx and BRs,
Zhongqiu Han
next prev parent reply other threads:[~2026-08-12 13:59 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-10 6:10 [PATCH] cpufreq: acpi-cpufreq: add NULL check for acpi_perf_data before freeing lirongqing
2026-08-10 6:10 ` [PATCH] cpufreq: acpi-cpufreq: Initialize cmd.val in drv_read() lirongqing
2026-08-10 12:15 ` Zhongqiu Han
2026-08-10 6:10 ` [PATCH] cpufreq: acpi-cpufreq: Using cpufreq_for_each_entry() to iterate in extract_io() lirongqing
2026-08-12 13:59 ` Zhongqiu Han [this message]
2026-08-10 11:21 ` [PATCH] cpufreq: acpi-cpufreq: add NULL check for acpi_perf_data before freeing Zhongqiu Han
2026-08-10 11:52 ` Zhongqiu Han
2026-08-12 12:06 ` 答复: [外部邮件] " Li,Rongqing
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=b375a4bb-2df2-4b9b-ba28-6ef153a89c70@oss.qualcomm.com \
--to=zhongqiu.han@oss.qualcomm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=lirongqing@baidu.com \
--cc=rafael@kernel.org \
--cc=viresh.kumar@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox