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: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-28 13:05 CVE-2022-48655: firmware: arm_scmi: Harden accesses to the reset domains Greg Kroah-Hartman
2024-05-10 3:12 ` 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.