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

[Michal Hocko <mhocko@suse.com>]

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