Message-ID: <2025042301-flammable-masculine-ec48@gregkh>
Date: Wed, 23 Apr 2025 10:21:04 +0200
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: Michal Hocko <mhocko@...e.com>
Cc: cve@...nel.org, linux-kernel@...r.kernel.org,
	linux-cve-announce@...r.kernel.org
Subject: Re: CVE-2024-56705: media: atomisp: Add check for rgby_data memory
 allocation failure

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

Powered by blists - more mailing lists