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

[Greg Kroah-Hartman <gregkh@linuxfoundation.org>]

On Fri, May 10, 2024 at 12:12:46PM +0900, Dominique Martinet wrote:
> meta-question: I've had a look at Documentation/process/cve.rst and
> while it describes how to report newly fixed issues, it doesn't describe
> how to add informations to already submitted CVEs.

Just email us!

> For some reason one of our customers saw this CVE through some news
> outlet and asked us if they were vulnerable (NVD flags this as
> high[1]...); so I had a quick look at the minimum version that could be
> updated for everyone.
> [1] https://nvd.nist.gov/vuln/detail/CVE-2022-48655

nvd is funny in that they have no way of knowing how any of this really
works, so please treat it as maybe a hint, but no more than that.

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

> Greg Kroah-Hartman wrote on Sun, Apr 28, 2024 at 03:05:16PM +0200:
> > Affected and fixed versions
> > ===========================
> > 
> > 	Fixed in 5.15.71 with commit 1f08a1b26cfc
> > 	Fixed in 5.19.12 with commit 8e65edf0d376
> > 	Fixed in 6.0 with commit e9076ffbcaed
> 
> These commits lacked a Fixes tag, so this CVE does not have a minimum
> version.
> 
> >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?

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

And yes, backported patches would be always appreciated for older
kernels if you have them.

thanks,

greg k-h