Message-ID: <aAiwaM5ru-FJG2fI@tiehlicka>
Date: Wed, 23 Apr 2025 11:18:32 +0200
From: Michal Hocko <mhocko@...e.com>
To: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
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 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

Powered by blists - more mailing lists