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

[Giovanni Gherdovich]

Hello,

On Mon Jun 2, 2025 14:51, Andre Przywara 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 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.

I see. Right, my initial comment regarding the ROM content was missing
the core of the problem.

> 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.

Ok, thanks for clarifying that in the present form, the code behaves
the same before and after the fix (the upper 16 bits discarded
anyway). Your fix improves the code and makes it future-proof.

Greg:

given this information, and Andre (developer of the change) saying at the
beginning of his message that he thinks the bug shouldn't be a CVE, do
you think the CVE can be revoked?


Thanks,
Giovanni