linux-kernel - Re: CVE-2022-48655: firmware: arm_scmi: Harden accesses to the reset domains

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <2024051148-fervor-aloft-43a3@gregkh>
Date: Sat, 11 May 2024 12:59:23 +0100
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: Dominique Martinet <asmadeus@...ewreck.org>
Cc: cve@...nel.org, linux-kernel@...r.kernel.org
Subject: Re: CVE-2022-48655: firmware: arm_scmi: Harden accesses to the reset
 domains

On Fri, May 10, 2024 at 11:23:30PM +0900, Dominique Martinet wrote:
> Greg Kroah-Hartman wrote on Fri, May 10, 2024 at 09:55:15AM +0100:
> > > I can submit an edit as a patch to vulns.git json, but this doesn't seem
> > > overly important so for now a mail will probably do.
> > 
> > the json and mbox files are generated by tools, so patches to them is
> > not a good idea as they will be overwritten the next time the scripts
> > are run.
> 
> Just let me know what's the most convenient; if mail it is I won't
> bother :)
> 
> > > >From a quick look it would seem it fixes arm_scmi from the addition of
> > > scmi_domain_reset() in 95a15d80aa0d ("firmware: arm_scmi: Add RESET
> > > protocol in SCMI v2.0"), which first appeared in v5.4-rc1, and does not
> > > appear to have been backported to older kernels, so v5.4+ can be added
> > > as a requirement.
> > 
> > We can add a "this is where the problem showed up" if you know it, so
> > that would be 95a15d80aa0d ("firmware: arm_scmi: Add RESET protocol in
> > SCMI v2.0"), correct?
> 
> Yes; this commit adds the out of bound access.

Great, I'll mark the cve as having that as the "vulnerable" commit id,
and then re-run the scripts and update the .json file and push it to
cve.org when I get back to a better network connection.

> > > This means the current 5.4/5.10 trees are affected; the commit doesn't
> > > backport cleanly because of a trivial context conflict so if that helps
> > > I can send a couple of stable patch if that helps even if our systems
> > > are not using arm_scmi (CVEs also don't have any way of expressing
> > > whether the affected driver is used (or even built) at all, so I guess
> > > people with affected versions will have to check that themselves...)
> > 
> > As everyone has different configurations, yes, everyone needs to check
> > themselves, there is no way for us to determine this at all.  But we do
> > list the files affected, so that should help you out in determining this
> > automatically on your end.
> 
> I didn't see hte list of files anywhere for this, does it depend on the
> commit?
> (not that it's a problem to look at the commits referenced, I don't
> think we'll automate anything for the forseeable future)

Yes, it depeneds on the commit that fixes the issue, and the mail
message for the CVE record says:

	The file(s) affected by this issue are:
		drivers/firmware/arm_scmi/reset.c

Note that we can not include this in the json record format because,
while cve has a field for this, it does not actually work properly for
file names (it wants a url for a filename, strange but true...)  This is
a bug on the cve.org end and hopefully will be fixed one day so that we
can provide the file name information in a machine-parsable format.

> > And yes, backported patches would be always appreciated for older
> > kernels if you have them.
> 
> Sure, I'll take a min to finish the patches and send them on Monday;
> might as well use work time when I've got an excuse to do kernel stuff.

Wonderful, thanks!

greg k-h