Message-ID: <aAjOK_f-GPFHIdWK@tiehlicka>
Date: Wed, 23 Apr 2025 13:25:31 +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 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

Powered by blists - more mailing lists