Re: CVE-2024-56705: media: atomisp: Add check for rgby_data memory allocation failure

Re: CVE-2024-56705: media: atomisp: Add check for rgby_data memory allocation failure

[Michal Hocko]

Hi,
our internal tools which are working with vulns.git tree have noticed
that this CVE entry has been altered after the announcement.

There was an additional commit added to the CVE entry. The current state
is
$ cat cve/published/2024/CVE-2024-56705.sha1
ed61c59139509f76d3592683c90dc3fdc6e23cd6
51b8dc5163d2ff2bf04019f8bf7e3bd0e75bb654

There seem to be handful of other cases like this one AFAICS.

I have 3 questions:
1) What is 51b8dc5163d2 ("media: staging: atomisp: Remove driver")
   relation to the original CVE which seems to be about a missing memory
   allocation failure check?
2) What is the process when a CVE is altered? have I missed any email
   notification?
3) Until now CVE -> sha was a 1:1 mapping. Can we expect this to change
   and what exactly is the process here?

Thanks!

On Sat 28-12-24 10:45:57, Greg KH wrote:
> Description
> ===========
> 
> In the Linux kernel, the following vulnerability has been resolved:
> 
> media: atomisp: Add check for rgby_data memory allocation failure
> 
> In ia_css_3a_statistics_allocate(), there is no check on the allocation
> result of the rgby_data memory. If rgby_data is not successfully
> allocated, it may trigger the assert(host_stats->rgby_data) assertion in
> ia_css_s3a_hmem_decode(). Adding a check to fix this potential issue.
> 
> The Linux kernel CVE team has assigned CVE-2024-56705 to this issue.
> 
> 
> Affected and fixed versions
> ===========================
> 
> 	Issue introduced in 4.12 with commit a49d25364dfb9f8a64037488a39ab1f56c5fa419 and fixed in 5.10.231 with commit 0c24b82bc4d12c6a58ceacbf2598cd4df63abf9a
> 	Issue introduced in 4.12 with commit a49d25364dfb9f8a64037488a39ab1f56c5fa419 and fixed in 5.15.174 with commit 4676e50444046b498555b849e6080a5c78cdda9b
> 	Issue introduced in 4.12 with commit a49d25364dfb9f8a64037488a39ab1f56c5fa419 and fixed in 6.1.120 with commit 02a97d9d7ff605fa4a1f908d1bd3ad8573234b61
> 	Issue introduced in 4.12 with commit a49d25364dfb9f8a64037488a39ab1f56c5fa419 and fixed in 6.6.64 with commit 8066badaf7463194473fb4be19dbe50b11969aa0
> 	Issue introduced in 4.12 with commit a49d25364dfb9f8a64037488a39ab1f56c5fa419 and fixed in 6.11.11 with commit 74aa783682c4d78c69d87898e40c78df1fec204e
> 	Issue introduced in 4.12 with commit a49d25364dfb9f8a64037488a39ab1f56c5fa419 and fixed in 6.12.2 with commit 0c25ab93f2878cab07d37ca5afd302283201e5af
> 	Issue introduced in 4.12 with commit a49d25364dfb9f8a64037488a39ab1f56c5fa419 and fixed in 6.13-rc1 with commit ed61c59139509f76d3592683c90dc3fdc6e23cd6
> 
> Please see https://www.kernel.org for a full list of currently supported
> kernel versions by the kernel community.
> 
> Unaffected versions might change over time as fixes are backported to
> older supported kernel versions.  The official CVE entry at
> 	https://cve.org/CVERecord/?id=CVE-2024-56705
> will be updated if fixes are backported, please check that for the most
> up to date information about this issue.
> 
> 
> Affected files
> ==============
> 
> The file(s) affected by this issue are:
> 	drivers/staging/media/atomisp/pci/sh_css_params.c
> 
> 
> Mitigation
> ==========
> 
> The Linux kernel CVE team recommends that you update to the latest
> stable kernel version for this, and many other bugfixes.  Individual
> changes are never tested alone, but rather are part of a larger kernel
> release.  Cherry-picking individual commits is not recommended or
> supported by the Linux kernel community at all.  If however, updating to
> the latest release is impossible, the individual changes to resolve this
> issue can be found at these commits:
> 	https://git.kernel.org/stable/c/0c24b82bc4d12c6a58ceacbf2598cd4df63abf9a
> 	https://git.kernel.org/stable/c/4676e50444046b498555b849e6080a5c78cdda9b
> 	https://git.kernel.org/stable/c/02a97d9d7ff605fa4a1f908d1bd3ad8573234b61
> 	https://git.kernel.org/stable/c/8066badaf7463194473fb4be19dbe50b11969aa0
> 	https://git.kernel.org/stable/c/74aa783682c4d78c69d87898e40c78df1fec204e
> 	https://git.kernel.org/stable/c/0c25ab93f2878cab07d37ca5afd302283201e5af
> 	https://git.kernel.org/stable/c/ed61c59139509f76d3592683c90dc3fdc6e23cd6

-- 
Michal Hocko
SUSE Labs

Re: CVE-2024-56705: media: atomisp: Add check for rgby_data memory allocation failure

[Greg Kroah-Hartman]

On Wed, Apr 23, 2025 at 09:54:08AM +0200, Michal Hocko wrote:
> Hi,
> our internal tools which are working with vulns.git tree have noticed
> that this CVE entry has been altered after the announcement.

Good catch!

> There was an additional commit added to the CVE entry. The current state
> is
> $ cat cve/published/2024/CVE-2024-56705.sha1
> ed61c59139509f76d3592683c90dc3fdc6e23cd6
> 51b8dc5163d2ff2bf04019f8bf7e3bd0e75bb654

Yup!

> There seem to be handful of other cases like this one AFAICS.

Yes, we had to add support for this type of problem.

> I have 3 questions:
> 1) What is 51b8dc5163d2 ("media: staging: atomisp: Remove driver")
>    relation to the original CVE which seems to be about a missing memory
>    allocation failure check?

Removing the driver entirely from the kernel "fixed" the vulnerability :)

> 2) What is the process when a CVE is altered? have I missed any email
>    notification?

We do not do email notifications when CVEs are altered.  You have to
watch the cve.org json feed for that.  Otherwise the email list would
just be too confusing.  Think about every new stable update that happens
which causes 10+ different CVEs to be updated showing where they are now
resolved.  That does not come across well in an email feed, but the json
feed shows it exactly.

Or you can follow the github cve feed, which shows this, OR you can just
follow the vulns.git git commits which also show this.

> 3) Until now CVE -> sha was a 1:1 mapping. Can we expect this to change
>    and what exactly is the process here?

The process has changed in that we have had to handle a number of CVEs
where both the commit that caused the vulnerabilty has been tracked to
mutiple commits (think of one-off changes that only happened on
different stable branches, and then were fixed with different commit
ids, like what happened in CVE-2025-40364), or this example you are
pointing out where a vulnerability was introduced, later removed by
having the entire driver removed, and then added back by adding the
driver back and then resolving the vulnerability.

The original CVE had this information as you point out:

 	Issue introduced in 4.12 with commit a49d25364dfb9f8a64037488a39ab1f56c5fa419 and fixed in 5.10.231 with commit 0c24b82bc4d12c6a58ceacbf2598cd4df63abf9a
 	Issue introduced in 4.12 with commit a49d25364dfb9f8a64037488a39ab1f56c5fa419 and fixed in 5.15.174 with commit 4676e50444046b498555b849e6080a5c78cdda9b
 	Issue introduced in 4.12 with commit a49d25364dfb9f8a64037488a39ab1f56c5fa419 and fixed in 6.1.120 with commit 02a97d9d7ff605fa4a1f908d1bd3ad8573234b61
 	Issue introduced in 4.12 with commit a49d25364dfb9f8a64037488a39ab1f56c5fa419 and fixed in 6.6.64 with commit 8066badaf7463194473fb4be19dbe50b11969aa0
 	Issue introduced in 4.12 with commit a49d25364dfb9f8a64037488a39ab1f56c5fa419 and fixed in 6.11.11 with commit 74aa783682c4d78c69d87898e40c78df1fec204e
 	Issue introduced in 4.12 with commit a49d25364dfb9f8a64037488a39ab1f56c5fa419 and fixed in 6.12.2 with commit 0c25ab93f2878cab07d37ca5afd302283201e5af
 	Issue introduced in 4.12 with commit a49d25364dfb9f8a64037488a39ab1f56c5fa419 and fixed in 6.13-rc1 with commit ed61c59139509f76d3592683c90dc3fdc6e23cd6

And now it shows this:

	Issue introduced in 4.12 with commit a49d25364dfb9f8a64037488a39ab1f56c5fa419 and fixed in 4.18 with commit 51b8dc5163d2ff2bf04019f8bf7e3bd0e75bb654
	Issue introduced in 5.8 with commit ad85094b293e40e7a2f831b0311a389d952ebd5e and fixed in 5.10.231 with commit 0c24b82bc4d12c6a58ceacbf2598cd4df63abf9a
	Issue introduced in 5.8 with commit ad85094b293e40e7a2f831b0311a389d952ebd5e and fixed in 5.15.174 with commit 4676e50444046b498555b849e6080a5c78cdda9b
	Issue introduced in 5.8 with commit ad85094b293e40e7a2f831b0311a389d952ebd5e and fixed in 6.1.120 with commit 02a97d9d7ff605fa4a1f908d1bd3ad8573234b61
	Issue introduced in 5.8 with commit ad85094b293e40e7a2f831b0311a389d952ebd5e and fixed in 6.6.64 with commit 8066badaf7463194473fb4be19dbe50b11969aa0
	Issue introduced in 5.8 with commit ad85094b293e40e7a2f831b0311a389d952ebd5e and fixed in 6.11.11 with commit 74aa783682c4d78c69d87898e40c78df1fec204e
	Issue introduced in 5.8 with commit ad85094b293e40e7a2f831b0311a389d952ebd5e and fixed in 6.12.2 with commit 0c25ab93f2878cab07d37ca5afd302283201e5af
	Issue introduced in 5.8 with commit ad85094b293e40e7a2f831b0311a389d952ebd5e and fixed in 6.13 with commit ed61c59139509f76d3592683c90dc3fdc6e23cd6

Showing that the kernel ranges from 4.18 -> 5.8 were NOT vulnerable to
this specific issue.  Information that is hopefully very valuable to
distros dealing with old kernels, like yours :)

So now we can properly handle this types of issues in an automated
fashion, thanks again for noticing, this was a non-trivial amount of
work to implement.  Given that no one had ever done this before, we have
had to create all of this "from scratch".

Our trees are crazy, hopefully this helps explain the lifecycle of
vulnerabilities and their fixes better than before.

One other note, perhaps you just want to parse the .dyad files we
create instead of mbox files?  That provides a machine-readable format
of what commits caused a specific vulnerability, and what commits fixed
it, if any, in any specific kernel branch that is known.  I know at
least one distro and one company that just relies on those files
directly instead of attempting to parse the crazy json output that
cve.org requires which in some places, I would argue, shows actually
incorrect information, but that's a different topic...

I really should write up more information about all of this one day, but
we've just been heads-down trying to implement all of this to deal with
the complexity involved in a way that is scalable over time.

Does that help?

thanks,

greg k-h

Re: CVE-2024-56705: media: atomisp: Add check for rgby_data memory allocation failure

[Michal Hocko]

On Wed 23-04-25 10:21:04, Greg KH wrote:
> On Wed, Apr 23, 2025 at 09:54:08AM +0200, Michal Hocko wrote:
> > Hi,
> > our internal tools which are working with vulns.git tree have noticed
> > that this CVE entry has been altered after the announcement.
> 
> Good catch!
> 
> > There was an additional commit added to the CVE entry. The current state
> > is
> > $ cat cve/published/2024/CVE-2024-56705.sha1
> > ed61c59139509f76d3592683c90dc3fdc6e23cd6
> > 51b8dc5163d2ff2bf04019f8bf7e3bd0e75bb654
> 
> Yup!
> 
> > There seem to be handful of other cases like this one AFAICS.
> 
> Yes, we had to add support for this type of problem.
> 
> > I have 3 questions:
> > 1) What is 51b8dc5163d2 ("media: staging: atomisp: Remove driver")
> >    relation to the original CVE which seems to be about a missing memory
> >    allocation failure check?
> 
> Removing the driver entirely from the kernel "fixed" the vulnerability :)

What is _the_ vulnerability? While I do understand that _any_ potential
vulnerability in the removed code is removed as well I still do not see
how the driver removal is related to _this_ specific CVE.

> > 2) What is the process when a CVE is altered? have I missed any email
> >    notification?
> 
> We do not do email notifications when CVEs are altered.  You have to
> watch the cve.org json feed for that.  Otherwise the email list would
> just be too confusing.  Think about every new stable update that happens
> which causes 10+ different CVEs to be updated showing where they are now
> resolved.  That does not come across well in an email feed, but the json
> feed shows it exactly.

I do understand you do not want to send notifications for that. Would it
make sense to announce a new upstream commit added to the CVE, though? This
would make it much easier to see that we might be missing a fix that is
considered related to a particular CVE.

> Or you can follow the github cve feed, which shows this, OR you can just
> follow the vulns.git git commits which also show this.
> 
> > 3) Until now CVE -> sha was a 1:1 mapping. Can we expect this to change
> >    and what exactly is the process here?
> 
> The process has changed in that we have had to handle a number of CVEs
> where both the commit that caused the vulnerabilty has been tracked to
> mutiple commits (think of one-off changes that only happened on
> different stable branches, and then were fixed with different commit
> ids, like what happened in CVE-2025-40364), or this example you are
> pointing out where a vulnerability was introduced, later removed by
> having the entire driver removed, and then added back by adding the
> driver back and then resolving the vulnerability.
> 
> The original CVE had this information as you point out:
> 
>  	Issue introduced in 4.12 with commit a49d25364dfb9f8a64037488a39ab1f56c5fa419 and fixed in 5.10.231 with commit 0c24b82bc4d12c6a58ceacbf2598cd4df63abf9a
>  	Issue introduced in 4.12 with commit a49d25364dfb9f8a64037488a39ab1f56c5fa419 and fixed in 5.15.174 with commit 4676e50444046b498555b849e6080a5c78cdda9b
>  	Issue introduced in 4.12 with commit a49d25364dfb9f8a64037488a39ab1f56c5fa419 and fixed in 6.1.120 with commit 02a97d9d7ff605fa4a1f908d1bd3ad8573234b61
>  	Issue introduced in 4.12 with commit a49d25364dfb9f8a64037488a39ab1f56c5fa419 and fixed in 6.6.64 with commit 8066badaf7463194473fb4be19dbe50b11969aa0
>  	Issue introduced in 4.12 with commit a49d25364dfb9f8a64037488a39ab1f56c5fa419 and fixed in 6.11.11 with commit 74aa783682c4d78c69d87898e40c78df1fec204e
>  	Issue introduced in 4.12 with commit a49d25364dfb9f8a64037488a39ab1f56c5fa419 and fixed in 6.12.2 with commit 0c25ab93f2878cab07d37ca5afd302283201e5af
>  	Issue introduced in 4.12 with commit a49d25364dfb9f8a64037488a39ab1f56c5fa419 and fixed in 6.13-rc1 with commit ed61c59139509f76d3592683c90dc3fdc6e23cd6
> 
> And now it shows this:
> 
> 	Issue introduced in 4.12 with commit a49d25364dfb9f8a64037488a39ab1f56c5fa419 and fixed in 4.18 with commit 51b8dc5163d2ff2bf04019f8bf7e3bd0e75bb654
> 	Issue introduced in 5.8 with commit ad85094b293e40e7a2f831b0311a389d952ebd5e and fixed in 5.10.231 with commit 0c24b82bc4d12c6a58ceacbf2598cd4df63abf9a
> 	Issue introduced in 5.8 with commit ad85094b293e40e7a2f831b0311a389d952ebd5e and fixed in 5.15.174 with commit 4676e50444046b498555b849e6080a5c78cdda9b
> 	Issue introduced in 5.8 with commit ad85094b293e40e7a2f831b0311a389d952ebd5e and fixed in 6.1.120 with commit 02a97d9d7ff605fa4a1f908d1bd3ad8573234b61
> 	Issue introduced in 5.8 with commit ad85094b293e40e7a2f831b0311a389d952ebd5e and fixed in 6.6.64 with commit 8066badaf7463194473fb4be19dbe50b11969aa0
> 	Issue introduced in 5.8 with commit ad85094b293e40e7a2f831b0311a389d952ebd5e and fixed in 6.11.11 with commit 74aa783682c4d78c69d87898e40c78df1fec204e
> 	Issue introduced in 5.8 with commit ad85094b293e40e7a2f831b0311a389d952ebd5e and fixed in 6.12.2 with commit 0c25ab93f2878cab07d37ca5afd302283201e5af
> 	Issue introduced in 5.8 with commit ad85094b293e40e7a2f831b0311a389d952ebd5e and fixed in 6.13 with commit ed61c59139509f76d3592683c90dc3fdc6e23cd6
> 
> Showing that the kernel ranges from 4.18 -> 5.8 were NOT vulnerable to
> this specific issue.  Information that is hopefully very valuable to
> distros dealing with old kernels, like yours :)

Nope, not really. Specific stable tree versions affected is not the most
important information to downstreams like ours. We really do care about
specific commits that are coupled with the CVE. If the specific commit
doesn't have Fixes tag then we look a the CVE-$FOO.vulnerable as well
(btw. I have a growing list of those that we have identified breakers
for and I am looking for the best way to contribute that information to
others. I am just not sure how to do that in the most efficient way -
sorry slightly offtopic here - we can follow up off the list.).

> So now we can properly handle this types of issues in an automated
> fashion, thanks again for noticing, this was a non-trivial amount of
> work to implement.  Given that no one had ever done this before, we have
> had to create all of this "from scratch".
> 
> Our trees are crazy, hopefully this helps explain the lifecycle of
> vulnerabilities and their fixes better than before.
> 
> One other note, perhaps you just want to parse the .dyad files we
> create instead of mbox files?

We are not parsing mbox files. We do care about CVE-$FOO.sha1 and that
provides the base for our future analysis. If we need to expect several
upstream commits there we are fine with that. Quite honestly seeing a
stream of CVEs all fixing the same vulnerability just because those
fixes happened in many commits doesn't seem to be optimal.
-- 
Michal Hocko
SUSE Labs

Re: CVE-2024-56705: media: atomisp: Add check for rgby_data memory allocation failure

[Greg Kroah-Hartman]

On Wed, Apr 23, 2025 at 11:18:32AM +0200, Michal Hocko wrote:
> On Wed 23-04-25 10:21:04, Greg KH wrote:
> > On Wed, Apr 23, 2025 at 09:54:08AM +0200, Michal Hocko wrote:
> > > Hi,
> > > our internal tools which are working with vulns.git tree have noticed
> > > that this CVE entry has been altered after the announcement.
> > 
> > Good catch!
> > 
> > > There was an additional commit added to the CVE entry. The current state
> > > is
> > > $ cat cve/published/2024/CVE-2024-56705.sha1
> > > ed61c59139509f76d3592683c90dc3fdc6e23cd6
> > > 51b8dc5163d2ff2bf04019f8bf7e3bd0e75bb654
> > 
> > Yup!
> > 
> > > There seem to be handful of other cases like this one AFAICS.
> > 
> > Yes, we had to add support for this type of problem.
> > 
> > > I have 3 questions:
> > > 1) What is 51b8dc5163d2 ("media: staging: atomisp: Remove driver")
> > >    relation to the original CVE which seems to be about a missing memory
> > >    allocation failure check?
> > 
> > Removing the driver entirely from the kernel "fixed" the vulnerability :)
> 
> What is _the_ vulnerability? While I do understand that _any_ potential
> vulnerability in the removed code is removed as well I still do not see
> how the driver removal is related to _this_ specific CVE.

"The" vulnerability is what is fixed in the last commit id, and is what
is documented in the text of the CVE, specifically:

	In ia_css_3a_statistics_allocate(), there is no check on the allocation
	result of the rgby_data memory. If rgby_data is not successfully
	allocated, it may trigger the assert(host_stats->rgby_data) assertion in
	ia_css_s3a_hmem_decode(). Adding a check to fix this potential issue.

That has not changed here at all.  It's just that the ranges of git
versions for when Linux was vulnerable to this issue has been "tightened
up" to only reflect when it was possible for this to be a problem (i.e.
we now do not count the range of releases where the driver was not
present at all in the kernel tree.)

> > > 2) What is the process when a CVE is altered? have I missed any email
> > >    notification?
> > 
> > We do not do email notifications when CVEs are altered.  You have to
> > watch the cve.org json feed for that.  Otherwise the email list would
> > just be too confusing.  Think about every new stable update that happens
> > which causes 10+ different CVEs to be updated showing where they are now
> > resolved.  That does not come across well in an email feed, but the json
> > feed shows it exactly.
> 
> I do understand you do not want to send notifications for that. Would it
> make sense to announce a new upstream commit added to the CVE, though? This
> would make it much easier to see that we might be missing a fix that is
> considered related to a particular CVE.

As this has only happened 2 times so far, it's a pretty rare occurance
given us allocating over 6000 CVEs.  And how exactly would that email
look like?

We are just changing the ranges here, we change ranges of where a kernel
is vulnerable all the time by adding new .vulnerable files to the tree
as people report them, and as fixes are backported to older stable
kernel trees.  That's much more important to you than this type of
change, right?

> > Showing that the kernel ranges from 4.18 -> 5.8 were NOT vulnerable to
> > this specific issue.  Information that is hopefully very valuable to
> > distros dealing with old kernels, like yours :)
> 
> Nope, not really. Specific stable tree versions affected is not the most
> important information to downstreams like ours. We really do care about
> specific commits that are coupled with the CVE. If the specific commit
> doesn't have Fixes tag then we look a the CVE-$FOO.vulnerable as well
> (btw. I have a growing list of those that we have identified breakers
> for and I am looking for the best way to contribute that information to
> others. I am just not sure how to do that in the most efficient way -
> sorry slightly offtopic here - we can follow up off the list.).

The simplest way is to send us patches to the repo that add .vulnerable
files for those CVE ids, like others have been doing.  Look at the git
history for many examples of this happening.

And yes, git ids are the most important thing, and now we have also
tightened up that range.  That can be shown in the diff to the dyad
file:

diff --git a/cve/published/2024/CVE-2024-56705.dyad b/cve/published/2024/CVE-2024-56705.dyad
index d4897cd95a08..41ccd4b840c1 100644
--- a/cve/published/2024/CVE-2024-56705.dyad
+++ b/cve/published/2024/CVE-2024-56705.dyad
@@ -1,9 +1,13 @@
-# dyad version: 0752e6917bd6
+# dyad version: 1.1.0
+#      getting vulnerable:fixed pairs for git id 51b8dc5163d2ff2bf04019f8bf7e3bd0e75bb654
 #      getting vulnerable:fixed pairs for git id ed61c59139509f76d3592683c90dc3fdc6e23cd6
-4.12:a49d25364dfb9f8a64037488a39ab1f56c5fa419:5.10.231:0c24b82bc4d12c6a58ceacbf2598cd4df63abf9a
-4.12:a49d25364dfb9f8a64037488a39ab1f56c5fa419:5.15.174:4676e50444046b498555b849e6080a5c78cdda9b
-4.12:a49d25364dfb9f8a64037488a39ab1f56c5fa419:6.1.120:02a97d9d7ff605fa4a1f908d1bd3ad8573234b61
-4.12:a49d25364dfb9f8a64037488a39ab1f56c5fa419:6.6.64:8066badaf7463194473fb4be19dbe50b11969aa0
-4.12:a49d25364dfb9f8a64037488a39ab1f56c5fa419:6.11.11:74aa783682c4d78c69d87898e40c78df1fec204e
-4.12:a49d25364dfb9f8a64037488a39ab1f56c5fa419:6.12.2:0c25ab93f2878cab07d37ca5afd302283201e5af
-4.12:a49d25364dfb9f8a64037488a39ab1f56c5fa419:6.13:ed61c59139509f76d3592683c90dc3fdc6e23cd6
+#      Setting original vulnerable kernel to be kernel 4.12 and git id a49d25364dfb9f8a64037488a39ab1f56c5fa419
+#      Setting original vulnerable kernel to be kernel 5.8 and git id ad85094b293e40e7a2f831b0311a389d952ebd5e
+4.12:a49d25364dfb9f8a64037488a39ab1f56c5fa419:4.18:51b8dc5163d2ff2bf04019f8bf7e3bd0e75bb654
+5.8:ad85094b293e40e7a2f831b0311a389d952ebd5e:5.10.231:0c24b82bc4d12c6a58ceacbf2598cd4df63abf9a
+5.8:ad85094b293e40e7a2f831b0311a389d952ebd5e:5.15.174:4676e50444046b498555b849e6080a5c78cdda9b
+5.8:ad85094b293e40e7a2f831b0311a389d952ebd5e:6.1.120:02a97d9d7ff605fa4a1f908d1bd3ad8573234b61
+5.8:ad85094b293e40e7a2f831b0311a389d952ebd5e:6.6.64:8066badaf7463194473fb4be19dbe50b11969aa0
+5.8:ad85094b293e40e7a2f831b0311a389d952ebd5e:6.11.11:74aa783682c4d78c69d87898e40c78df1fec204e
+5.8:ad85094b293e40e7a2f831b0311a389d952ebd5e:6.12.2:0c25ab93f2878cab07d37ca5afd302283201e5af
+5.8:ad85094b293e40e7a2f831b0311a389d952ebd5e:6.13:ed61c59139509f76d3592683c90dc3fdc6e23cd6

> > So now we can properly handle this types of issues in an automated
> > fashion, thanks again for noticing, this was a non-trivial amount of
> > work to implement.  Given that no one had ever done this before, we have
> > had to create all of this "from scratch".
> > 
> > Our trees are crazy, hopefully this helps explain the lifecycle of
> > vulnerabilities and their fixes better than before.
> > 
> > One other note, perhaps you just want to parse the .dyad files we
> > create instead of mbox files?
> 
> We are not parsing mbox files. We do care about CVE-$FOO.sha1 and that
> provides the base for our future analysis. If we need to expect several
> upstream commits there we are fine with that. Quite honestly seeing a
> stream of CVEs all fixing the same vulnerability just because those
> fixes happened in many commits doesn't seem to be optimal.

I don't see any multiple CVEs happening here for the same issue, so I do
not understand what you are referring to.

Again, try following the .dyad files.  I think that will help you out a
lot more.

thanks,

greg k-h

Re: CVE-2024-56705: media: atomisp: Add check for rgby_data memory allocation failure

[Michal Hocko]

On Wed 23-04-25 12:20:47, Greg KH wrote:
> On Wed, Apr 23, 2025 at 11:18:32AM +0200, Michal Hocko wrote:
> > On Wed 23-04-25 10:21:04, Greg KH wrote:
> > > On Wed, Apr 23, 2025 at 09:54:08AM +0200, Michal Hocko wrote:
> > > > Hi,
> > > > our internal tools which are working with vulns.git tree have noticed
> > > > that this CVE entry has been altered after the announcement.
> > > 
> > > Good catch!
> > > 
> > > > There was an additional commit added to the CVE entry. The current state
> > > > is
> > > > $ cat cve/published/2024/CVE-2024-56705.sha1
> > > > ed61c59139509f76d3592683c90dc3fdc6e23cd6
> > > > 51b8dc5163d2ff2bf04019f8bf7e3bd0e75bb654
> > > 
> > > Yup!
> > > 
> > > > There seem to be handful of other cases like this one AFAICS.
> > > 
> > > Yes, we had to add support for this type of problem.
> > > 
> > > > I have 3 questions:
> > > > 1) What is 51b8dc5163d2 ("media: staging: atomisp: Remove driver")
> > > >    relation to the original CVE which seems to be about a missing memory
> > > >    allocation failure check?
> > > 
> > > Removing the driver entirely from the kernel "fixed" the vulnerability :)
> > 
> > What is _the_ vulnerability? While I do understand that _any_ potential
> > vulnerability in the removed code is removed as well I still do not see
> > how the driver removal is related to _this_ specific CVE.
> 
> "The" vulnerability is what is fixed in the last commit id, and is what
> is documented in the text of the CVE, specifically:
> 
> 	In ia_css_3a_statistics_allocate(), there is no check on the allocation
> 	result of the rgby_data memory. If rgby_data is not successfully
> 	allocated, it may trigger the assert(host_stats->rgby_data) assertion in
> 	ia_css_s3a_hmem_decode(). Adding a check to fix this potential issue.

I do understand this statement.

> That has not changed here at all.  It's just that the ranges of git
> versions for when Linux was vulnerable to this issue has been "tightened
> up" to only reflect when it was possible for this to be a problem (i.e.
> we now do not count the range of releases where the driver was not
> present at all in the kernel tree.)

But I fail to follow this. The commit itself says Fixes: a49d25364dfb
("staging/atomisp: Add support for the Intel IPU v2") which makes it
clear since when the issue has been introduced. If this tag was not
present then there is CVE-$FOO.vulnerable which can specify the same
thing. I do not understand how 51b8dc5163d2 is related as it has a
different implementation of ia_css_3a_statistics_allocate that doesn't
have any unchecked kernel allocations AFAICS.
 
> > > > 2) What is the process when a CVE is altered? have I missed any email
> > > >    notification?
> > > 
> > > We do not do email notifications when CVEs are altered.  You have to
> > > watch the cve.org json feed for that.  Otherwise the email list would
> > > just be too confusing.  Think about every new stable update that happens
> > > which causes 10+ different CVEs to be updated showing where they are now
> > > resolved.  That does not come across well in an email feed, but the json
> > > feed shows it exactly.
> > 
> > I do understand you do not want to send notifications for that. Would it
> > make sense to announce a new upstream commit added to the CVE, though? This
> > would make it much easier to see that we might be missing a fix that is
> > considered related to a particular CVE.
> 
> As this has only happened 2 times so far, it's a pretty rare occurance
> given us allocating over 6000 CVEs.  And how exactly would that email
> look like?

We have identified that CVE-$FOO fix has been incomplete so far and
extended list of fixes required for this CVE. Please make sure that
those are appplied.

Or something in those lines.

> We are just changing the ranges here, we change ranges of where a kernel
> is vulnerable all the time by adding new .vulnerable files to the tree
> as people report them, and as fixes are backported to older stable
> kernel trees.  That's much more important to you than this type of
> change, right?

Nope, being aware of what is actually the CVE fix is the most important
information. Which kernels are affected specifcally is something that is
downstream specific and stable tree ranges are only of a value to those
who are using stable trees. Updates to vulnerable files is helpful
during evaluation phase but once the assessment is done it acts mostly
as a double check.
-- 
Michal Hocko
SUSE Labs

Re: CVE-2024-56705: media: atomisp: Add check for rgby_data memory allocation failure

[Greg Kroah-Hartman]

On Wed, Apr 23, 2025 at 01:25:31PM +0200, Michal Hocko wrote:
> On Wed 23-04-25 12:20:47, Greg KH wrote:
> > On Wed, Apr 23, 2025 at 11:18:32AM +0200, Michal Hocko wrote:
> > > On Wed 23-04-25 10:21:04, Greg KH wrote:
> > > > On Wed, Apr 23, 2025 at 09:54:08AM +0200, Michal Hocko wrote:
> > > > > Hi,
> > > > > our internal tools which are working with vulns.git tree have noticed
> > > > > that this CVE entry has been altered after the announcement.
> > > > 
> > > > Good catch!
> > > > 
> > > > > There was an additional commit added to the CVE entry. The current state
> > > > > is
> > > > > $ cat cve/published/2024/CVE-2024-56705.sha1
> > > > > ed61c59139509f76d3592683c90dc3fdc6e23cd6
> > > > > 51b8dc5163d2ff2bf04019f8bf7e3bd0e75bb654
> > > > 
> > > > Yup!
> > > > 
> > > > > There seem to be handful of other cases like this one AFAICS.
> > > > 
> > > > Yes, we had to add support for this type of problem.
> > > > 
> > > > > I have 3 questions:
> > > > > 1) What is 51b8dc5163d2 ("media: staging: atomisp: Remove driver")
> > > > >    relation to the original CVE which seems to be about a missing memory
> > > > >    allocation failure check?
> > > > 
> > > > Removing the driver entirely from the kernel "fixed" the vulnerability :)
> > > 
> > > What is _the_ vulnerability? While I do understand that _any_ potential
> > > vulnerability in the removed code is removed as well I still do not see
> > > how the driver removal is related to _this_ specific CVE.
> > 
> > "The" vulnerability is what is fixed in the last commit id, and is what
> > is documented in the text of the CVE, specifically:
> > 
> > 	In ia_css_3a_statistics_allocate(), there is no check on the allocation
> > 	result of the rgby_data memory. If rgby_data is not successfully
> > 	allocated, it may trigger the assert(host_stats->rgby_data) assertion in
> > 	ia_css_s3a_hmem_decode(). Adding a check to fix this potential issue.
> 
> I do understand this statement.

That is the commit information, and as such we deemed it a
vulnerability.

> 
> > That has not changed here at all.  It's just that the ranges of git
> > versions for when Linux was vulnerable to this issue has been "tightened
> > up" to only reflect when it was possible for this to be a problem (i.e.
> > we now do not count the range of releases where the driver was not
> > present at all in the kernel tree.)
> 
> But I fail to follow this. The commit itself says Fixes: a49d25364dfb
> ("staging/atomisp: Add support for the Intel IPU v2") which makes it
> clear since when the issue has been introduced. If this tag was not
> present then there is CVE-$FOO.vulnerable which can specify the same
> thing. I do not understand how 51b8dc5163d2 is related as it has a
> different implementation of ia_css_3a_statistics_allocate that doesn't
> have any unchecked kernel allocations AFAICS.

Ah, ok, that changes things.  The person who said that we should count
the previous version of the driver said it was vulnerable at that point
when it was in the kernel tree.  If this isn't the case, we will be glad
to change this CVE to reflect that.

> > > > > 2) What is the process when a CVE is altered? have I missed any email
> > > > >    notification?
> > > > 
> > > > We do not do email notifications when CVEs are altered.  You have to
> > > > watch the cve.org json feed for that.  Otherwise the email list would
> > > > just be too confusing.  Think about every new stable update that happens
> > > > which causes 10+ different CVEs to be updated showing where they are now
> > > > resolved.  That does not come across well in an email feed, but the json
> > > > feed shows it exactly.
> > > 
> > > I do understand you do not want to send notifications for that. Would it
> > > make sense to announce a new upstream commit added to the CVE, though? This
> > > would make it much easier to see that we might be missing a fix that is
> > > considered related to a particular CVE.
> > 
> > As this has only happened 2 times so far, it's a pretty rare occurance
> > given us allocating over 6000 CVEs.  And how exactly would that email
> > look like?
> 
> We have identified that CVE-$FOO fix has been incomplete so far and
> extended list of fixes required for this CVE. Please make sure that
> those are appplied.
> 
> Or something in those lines.

Again, that would happen every stable release, and every -rc release,
could you really keep up with such an email flow in a way that wouldn't
just mirror watching the json feed instead?

> > We are just changing the ranges here, we change ranges of where a kernel
> > is vulnerable all the time by adding new .vulnerable files to the tree
> > as people report them, and as fixes are backported to older stable
> > kernel trees.  That's much more important to you than this type of
> > change, right?
> 
> Nope, being aware of what is actually the CVE fix is the most important
> information. Which kernels are affected specifcally is something that is
> downstream specific and stable tree ranges are only of a value to those
> who are using stable trees. Updates to vulnerable files is helpful
> during evaluation phase but once the assessment is done it acts mostly
> as a double check.

.vulnerable files get added all the time, so hopefully you are catching
those updates :)

thanks,

greg k-h

Re: CVE-2024-56705: media: atomisp: Add check for rgby_data memory allocation failure

[Michal Hocko]

On Wed 23-04-25 16:50:48, Greg KH wrote:
> On Wed, Apr 23, 2025 at 01:25:31PM +0200, Michal Hocko wrote:
> > On Wed 23-04-25 12:20:47, Greg KH wrote:
[...]
> > > 	In ia_css_3a_statistics_allocate(), there is no check on the allocation
> > > 	result of the rgby_data memory. If rgby_data is not successfully
> > > 	allocated, it may trigger the assert(host_stats->rgby_data) assertion in
> > > 	ia_css_s3a_hmem_decode(). Adding a check to fix this potential issue.
> > 
> > I do understand this statement.
> 
> That is the commit information, and as such we deemed it a
> vulnerability.
> 
> > 
> > > That has not changed here at all.  It's just that the ranges of git
> > > versions for when Linux was vulnerable to this issue has been "tightened
> > > up" to only reflect when it was possible for this to be a problem (i.e.
> > > we now do not count the range of releases where the driver was not
> > > present at all in the kernel tree.)
> > 
> > But I fail to follow this. The commit itself says Fixes: a49d25364dfb
> > ("staging/atomisp: Add support for the Intel IPU v2") which makes it
> > clear since when the issue has been introduced. If this tag was not
> > present then there is CVE-$FOO.vulnerable which can specify the same
> > thing. I do not understand how 51b8dc5163d2 is related as it has a
> > different implementation of ia_css_3a_statistics_allocate that doesn't
> > have any unchecked kernel allocations AFAICS.
> 
> Ah, ok, that changes things.  The person who said that we should count
> the previous version of the driver said it was vulnerable at that point
> when it was in the kernel tree.  If this isn't the case, we will be glad
> to change this CVE to reflect that.

OK, so I have dived into this deeper just to be sure 
	- fix ed61c5913950 merged v6.13-rc1
	- breaker: the commit says Fixes: a49d25364dfb merged v4.12-rc1 which
	  indeed adds  ia_css_3a_statistics_allocate and uses it in atomisp_alloc_3a_output_buf
	- now we have 51b8dc5163d2 ("media: staging: atomisp: Remove driver")
	  merged 4.18 mentioned in .sha1 file which drops the whole
	  driver. The driver was later reintroduced by ad85094b293e in v5.8-rc1
	- that being said the kernel has been vulnerable since 4.12
	  until 4.18 and 5.8 until 6.13. There is a gap when the code
	  was not there and the kernel was therefore not affected. 
All that being said I do understand the second entry now but considering
the first entry and its Fixes tag I believe the second entry is simply
redundant.

CVE-2024-53204, CVE-2024-53205 are the same situation.

CVE-2025-40364 is different. Both of the sha1 entries are stable
specific commits (same change) with a references to Fixes: c7fb19428d67d
merged in v5.19-rc1. This one has a follow up fix merged in fc9375e3f763
v5.19-rc3. 
So this CVE seems like stable specific (probably a misbackport?) or is this
a mistake?

> > > > > > 2) What is the process when a CVE is altered? have I missed any email
> > > > > >    notification?
> > > > > 
> > > > > We do not do email notifications when CVEs are altered.  You have to
> > > > > watch the cve.org json feed for that.  Otherwise the email list would
> > > > > just be too confusing.  Think about every new stable update that happens
> > > > > which causes 10+ different CVEs to be updated showing where they are now
> > > > > resolved.  That does not come across well in an email feed, but the json
> > > > > feed shows it exactly.
> > > > 
> > > > I do understand you do not want to send notifications for that. Would it
> > > > make sense to announce a new upstream commit added to the CVE, though? This
> > > > would make it much easier to see that we might be missing a fix that is
> > > > considered related to a particular CVE.
> > > 
> > > As this has only happened 2 times so far, it's a pretty rare occurance
> > > given us allocating over 6000 CVEs.  And how exactly would that email
> > > look like?
> > 
> > We have identified that CVE-$FOO fix has been incomplete so far and
> > extended list of fixes required for this CVE. Please make sure that
> > those are appplied.
> > 
> > Or something in those lines.
> 
> Again, that would happen every stable release, and every -rc release,
> could you really keep up with such an email flow in a way that wouldn't
> just mirror watching the json feed instead?

AFAICS there usually are no updates to CVE-$FOO.sha1 file and that is what
really matters to us to identify all the commits that are associated
with the specific CVE.

-- 
Michal Hocko
SUSE Labs

Re: CVE-2024-56705: media: atomisp: Add check for rgby_data memory allocation failure

[Greg Kroah-Hartman]

On Thu, Apr 24, 2025 at 11:59:35AM +0200, Michal Hocko wrote:
> On Wed 23-04-25 16:50:48, Greg KH wrote:
> > On Wed, Apr 23, 2025 at 01:25:31PM +0200, Michal Hocko wrote:
> > > On Wed 23-04-25 12:20:47, Greg KH wrote:
> [...]
> > > > 	In ia_css_3a_statistics_allocate(), there is no check on the allocation
> > > > 	result of the rgby_data memory. If rgby_data is not successfully
> > > > 	allocated, it may trigger the assert(host_stats->rgby_data) assertion in
> > > > 	ia_css_s3a_hmem_decode(). Adding a check to fix this potential issue.
> > > 
> > > I do understand this statement.
> > 
> > That is the commit information, and as such we deemed it a
> > vulnerability.
> > 
> > > 
> > > > That has not changed here at all.  It's just that the ranges of git
> > > > versions for when Linux was vulnerable to this issue has been "tightened
> > > > up" to only reflect when it was possible for this to be a problem (i.e.
> > > > we now do not count the range of releases where the driver was not
> > > > present at all in the kernel tree.)
> > > 
> > > But I fail to follow this. The commit itself says Fixes: a49d25364dfb
> > > ("staging/atomisp: Add support for the Intel IPU v2") which makes it
> > > clear since when the issue has been introduced. If this tag was not
> > > present then there is CVE-$FOO.vulnerable which can specify the same
> > > thing. I do not understand how 51b8dc5163d2 is related as it has a
> > > different implementation of ia_css_3a_statistics_allocate that doesn't
> > > have any unchecked kernel allocations AFAICS.
> > 
> > Ah, ok, that changes things.  The person who said that we should count
> > the previous version of the driver said it was vulnerable at that point
> > when it was in the kernel tree.  If this isn't the case, we will be glad
> > to change this CVE to reflect that.
> 
> OK, so I have dived into this deeper just to be sure 
> 	- fix ed61c5913950 merged v6.13-rc1
> 	- breaker: the commit says Fixes: a49d25364dfb merged v4.12-rc1 which
> 	  indeed adds  ia_css_3a_statistics_allocate and uses it in atomisp_alloc_3a_output_buf
> 	- now we have 51b8dc5163d2 ("media: staging: atomisp: Remove driver")
> 	  merged 4.18 mentioned in .sha1 file which drops the whole
> 	  driver. The driver was later reintroduced by ad85094b293e in v5.8-rc1
> 	- that being said the kernel has been vulnerable since 4.12
> 	  until 4.18 and 5.8 until 6.13. There is a gap when the code
> 	  was not there and the kernel was therefore not affected. 
> All that being said I do understand the second entry now but considering
> the first entry and its Fixes tag I believe the second entry is simply
> redundant.

Redundant if you are just using the .sha1 files, yes.  Not if you use
the .dyad files which show you exactly what you came up with here.

So for now, let's leave the .sha1 file alone, as without that second
commit in there, the tools can not figure out what you just determined
above in a programatic way.  Or if you think they can, hey, patches are
always gladly accepted!  The tools are now in rust, not crazy bash, with
a regression test suite, and any help is always welcome.

> CVE-2024-53204, CVE-2024-53205 are the same situation.
> 
> CVE-2025-40364 is different. Both of the sha1 entries are stable
> specific commits (same change) with a references to Fixes: c7fb19428d67d
> merged in v5.19-rc1. This one has a follow up fix merged in fc9375e3f763
> v5.19-rc3. 
> So this CVE seems like stable specific (probably a misbackport?) or is this
> a mistake?

It is a stable-specific CVE.  It's not the first time we've had this,
and will probably not be the last.

> > > > > > > 2) What is the process when a CVE is altered? have I missed any email
> > > > > > >    notification?
> > > > > > 
> > > > > > We do not do email notifications when CVEs are altered.  You have to
> > > > > > watch the cve.org json feed for that.  Otherwise the email list would
> > > > > > just be too confusing.  Think about every new stable update that happens
> > > > > > which causes 10+ different CVEs to be updated showing where they are now
> > > > > > resolved.  That does not come across well in an email feed, but the json
> > > > > > feed shows it exactly.
> > > > > 
> > > > > I do understand you do not want to send notifications for that. Would it
> > > > > make sense to announce a new upstream commit added to the CVE, though? This
> > > > > would make it much easier to see that we might be missing a fix that is
> > > > > considered related to a particular CVE.
> > > > 
> > > > As this has only happened 2 times so far, it's a pretty rare occurance
> > > > given us allocating over 6000 CVEs.  And how exactly would that email
> > > > look like?
> > > 
> > > We have identified that CVE-$FOO fix has been incomplete so far and
> > > extended list of fixes required for this CVE. Please make sure that
> > > those are appplied.
> > > 
> > > Or something in those lines.
> > 
> > Again, that would happen every stable release, and every -rc release,
> > could you really keep up with such an email flow in a way that wouldn't
> > just mirror watching the json feed instead?
> 
> AFAICS there usually are no updates to CVE-$FOO.sha1 file and that is what
> really matters to us to identify all the commits that are associated
> with the specific CVE.

Hopefully you all have the same tooling in place that we've created to
dig through the git repo to track what has been backported where.  But
again, if not, feel free to use the .dyad files which show you all of
the needed information in a machine readable format :)

thanks,

greg k-h