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

[Greg KH <gregkh@linuxfoundation.org>]

On Mon, Jun 02, 2025 at 06:28:31PM +0200, Giovanni Gherdovich wrote:
> 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?

Now revoked, thanks!

greg k-h