答复: [外部邮件] Re: [PATCH] cpufreq: a cpi-cpufreq: Using cpufreq_for_each_entry() t o iterate in extract_io()

"Li,Rongqing" <[email protected]>
Newsgroups org.kernel.vger.linux-pm,org.kernel.vger.linux-kernel
Message-ID <[email protected]>

> > From: Li RongQing <[email protected]>
> >
> > 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 <[email protected]>
> > ---
> >   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
> [email protected] doesn't get missed. Thanks
> 

I will send v2,thanks

[Li,Rongqing] 


> 
> >
> 
> 
> --
> Thx and BRs,
> Zhongqiu Han
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.