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]

Date: Fri, 10 May 2024 23:23:30 +0900
From: Dominique Martinet <asmadeus@...ewreck.org>
To: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc: cve@...nel.org, linux-kernel@...r.kernel.org
Subject: Re: CVE-2022-48655: firmware: arm_scmi: Harden accesses to the reset
 domains

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.

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

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


Thanks,
-- 
Dominique Martinet | Asmadeus