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.
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
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.
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.
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...)
Thanks,
--
Dominique Martinet | Asmadeus
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
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
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
On Sat, May 11, 2024 at 12:59:23PM +0100, Greg Kroah-Hartman wrote:
> 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.
Now updated on the cve.org web site, thanks!
greg k-h