From: Dominique Martinet <asmadeus@codewreck.org>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: cve@kernel.org, linux-kernel@vger.kernel.org
Subject: Re: CVE-2022-48655: firmware: arm_scmi: Harden accesses to the reset domains
Date: Fri, 10 May 2024 23:23:30 +0900 [thread overview]
Message-ID: <Zj4t4q_w6gqzdvhz@codewreck.org> (raw)
In-Reply-To: <2024051041-resisting-chatroom-32c8@gregkh>
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
next prev parent reply other threads:[~2024-05-10 14:23 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <2024042859-CVE-2022-48655-5feb@gregkh>
2024-05-10 3:12 ` CVE-2022-48655: firmware: arm_scmi: Harden accesses to the reset domains Dominique Martinet
2024-05-10 8:55 ` Greg Kroah-Hartman
2024-05-10 14:23 ` Dominique Martinet [this message]
2024-05-11 11:59 ` Greg Kroah-Hartman
2024-05-11 12:24 ` Greg Kroah-Hartman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Zj4t4q_w6gqzdvhz@codewreck.org \
--to=asmadeus@codewreck.org \
--cc=cve@kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox