Date: Thu, 23 May 2024 10:26:56 +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-35906: drm/amd/display: Send DTBCLK disable message on
 first commit

On Wed 22-05-24 05:57:38, Greg KH wrote:
[...]
> > I completely do get why you do not care about that downstream
> > engineering cost but generating bogus CVEs on top of a huge pile of
> > dubious ones is less than useful, don't you think?
> 
> How is this a "bogus" CVE on their own?

I suspect you haven't looked at those commits. This is a boot time
suboptimal HW configuration. There is no way any user can exploit that I
can see. Not to mention it cases system boot hangs!

[...]
> > Seriously, we can disagree whether something is a security threat that
> > is worth marking by a CVE. But making the CVE generation process mostly
> > unattended script driven process without any _serious_ review in place
> > is burning a lot of man power that could be used in a much more
> > productive way. This is not the way how to convince people to use stable
> > kernels.
> 
> To think that any of this is an "unattended script without any _serious_
> review" is slandering all of the people who put in their free time to do
> this work for you and the community.  This is ANYTHING BUT an unattended
> script.

This is a perception one can easily draw by watching the stream of
incoming flow. Sorry if that is not the case but there is about zero
transparency about the process except for Documentation/process/cve.rst
and let me quote
"
As part of the normal stable release process, kernel changes that are
potentially security issues are identified by the developers responsible
for CVE number assignments and have CVE numbers automatically assigned
to them.
"

There is no mention about criteria, review process. Who is involve in
the assignment and who is doing the review. The vulns.git tree doesn't
contain Sign-off-by of those involved parties except for the submitter.

> Also, this is work ostensibly that you are also already doing for your
> day-job, right?

We, like stable trees, rely on Fixes tag and those (including other
commits that might be this tag) are reviewed by domain experts.

[...]

> I appreciate your reviews so far of "hey, this shouldn't really be a
> CVE, right?"  That's a lot of help and is making things better, but to
> insinuate that somehow we don't know what the hell we are doing, or that
> we are doing nothing other than a simple "assign everything!" process
> here is extremely insulting to me and to the other developers here
> working on this.

I am sorry if you feel that way but I haven't said anything like that.

I have raised a concern based on observed CVE flow that the current
process is automated without a proper review as I can see very dubious
CVEs being assigned (splats resembling oops/warnings coming from lockdep,
data_race fixes as they resemble race condition fixes, READ_ONCE fixes
which do not fix anything discussed in other thread and others).

I have tried to dispute quite some but quickly learned that many of them
have been dismissed because "no usecases are assumed". It is a very
broad category that could indeed make any fix a CVE.

If you really want to build a trust around the CVE process then make it
more transparent. I would start by adding reason why something has been
marked CVE. You are saying there is peer review process going on then
why not add Reviewed-by: to make it explicit and visible.

Thanks!

-- 
Michal Hocko
SUSE Labs

Powered by blists - more mailing lists