Re: CVE-2025-37832: cpufreq: sun50i: prevent out-of-bounds access

[Andre Przywara <andre.przywara@arm.com>]

On Fri, 30 May 2025 20:00:37 +0200
Giovanni Gherdovich <giovanni.gherdovich@suse.com> wrote:

Hi,

I don't think this qualifies as a CVE, the issue was more theoretical. But
I don't have much experience with what deserves a CVE and what not, so I
can just present some insights:

> On Fri May 30, 2025 16:15, Greg KH wrote:
> > On Fri, May 30, 2025 at 04:14:51PM +0200, Greg KH wrote:  
> >> On Fri, May 30, 2025 at 03:57:35PM +0200, Giovanni Gherdovich wrote:  
> >>> On Thu May 8, 2025 08:39, Greg Kroah-Hartman wrote:  
> >>>> A KASAN enabled kernel reports an out-of-bounds access when handling the
> >>>> nvmem cell in the sun50i cpufreq driver:
> >>>> [...]  
> >>>
> >>> The invalid data that may be read comes from a ROM in the SoC,
> >>> programmed by the vendor, and is only used to configure CPU frequency
> >>> and voltage in the cpufreq framework.

So "potentially invalid data read from the ROM" is an issue the we have
regardless, this patch doesn't change that. And you cannot put arbitrary
voltages or frequencies in the OTP fuses, the value read is just used to
select one of the OPPs defined in the DT. If you want to attack the
system by heavily overclocking or baking it with a high voltage, you can
just change the limits in the DT. Not sure if that's easier or harder than
accessing the hardware, though.

But more importantly, looking at this particular patch: This effectively
limits the access size of the value we read from the SID OTP driver, from
always 4 bytes to what the DT says, typically 2 bytes. But we actually
mask the value in the code anyway later at the moment, so the upper 16
bits are always discarded.
Which means that as it stands at the moment, there is no real change in
what values are used. I just did the change as it was clearly incorrect,
and I wanted to prevent any issues, in case of code changes later.

Hope that helps!

Cheers,
Andre

> >>>
> >>> Even assuming that improper frequency/voltage settings constitute a
> >>> security risk, writing to the ROM in question is at least a privileged
> >>> operation, and may require physical access to the SoC.  
> >>
> >> Obviously there are systems out there that have this issue, with device
> >> trees that can trigger this issue, this isn't a matter of "malicious ROM
> >> doing bad things" type of issue, it's a "the DT can't express this
> >> properly, so we might have taken data from the hardware and handled it
> >> in the wrong way" type of issue.
> >>  
> >>> I don't think this qualifies as vulnerability.  
> >>
> >> I don't see how this is a ROM configuration issue, but rather just a
> >> kernel bug in how the hardware is accessed on different types of systems
> >> where we previously could not handle such accesses correctly.  
> 
> Thanks for clarifying this aspect. I'll move to a different objection,
> which is that the incorrect power management configuration that may
> result from this bug doesn't constitute a security vulnerability.
> It seems to me the CPU won't run at the intended clock, which is
> definitely a bug but not a CVE.
> 
> I'm CC'ing the change author and the subsystem maintainers to hear their
> opinion.
> 
> > Note, if the maintainer or the developer of the change in question here
> > disagrees with me, great, we'll be glad to revoke this CVE, as we defer
> > to them.  But for some reason you didn't include them in this thread :(  
> 
> Sure, you're right, I forgot to include them, fixed now.
> 
> Yangtao Li, Rafael, Viresh, Andre:
> I'm asking Greg and the kernel CNA to reconsider the assignment of CVE
> status to the bug fixed by 14c8a418159e541d70dbf8fc71225d1623beaf0f
> ("cpufreq: sun50i: prevent out-of-bounds access").
> You can find the CVE announcement email at
> https://lore.kernel.org/linux-cve-announce/2025050824-CVE-2025-37832-e235@gregkh/
> 
> If any of you thinks the status of CVE is well justified in this case,
> I'd appreciated if you could reply here, so I can make a mental note
> for similar future cases.
> 
> Thanks,
> Giovanni