Message-ID: <ZlBnsEsr66mR-frf@tiehlicka>
Date: Fri, 24 May 2024 12:10: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 Thu 23-05-24 15:49:59, Greg KH wrote:
> On Thu, May 23, 2024 at 10:26:56AM +0200, Michal Hocko wrote:
> > 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!
> 
> Yes, you are correct, the original should not have had a CVE assigned to
> it, that was wrong, and I have rejected it now.  Same for the revert, it
> too is now rejected.  Thanks for the review, it is much appreciated.

Thanks for considering the feedback!

> Also, the reason the original had a cve assigned to it was a fault on my
> side, that shouldn't have happened, and I've re-reviewed to make sure
> that I didn't mark anything else that way as well (so far I have not
> found anything, the 'revert' caused problems in our tools, not to blame
> them, but me, the author of that tool...)

Good to hear this has an explanation.

[...]
> Because of asking, many others are starting to help out, you can too,
> just submit patches against the cve/review/proposed/ directory with a
> list of commits that you feel should have CVEs assigned for, or annotate
> why you feel specific ones we have reviewed should NOT have a CVE
> assigned, and our tools can handle them quite well as part of the
> assignment process (see scripts/cve_review for a tool that some of us
> use to create these files, that's not required, as not all of us use it,
> but the output format is the key, and that's a simple list of commit
> ids, personally I generate that from mboxes.)

Do I get it right that proposals shouldn't be sent via email to
cve@...nel.org as suggested by the in tree documentation? I do not mind
the specific workflow but until now I have followed Documentation/process/cve.rst
as authoritative source of the process. It would be really great if that
matched the workflow.

> > > 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.
> 
> Great, so you already have reviewed all of these, so it should be a
> simple match up on your end.

Not at all. Every incoming CVE has to go through CVSS assessment at
least. This on its own is a very non-trivial and time consuming task
that obviously scales with the number of CVEs. There is more going
on besides that. 

[...]

> > 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.
> 
> We have that, see the git log of the cve/review/ directory for the files
> and where most all of the cves come from.  Some come directly from
> requests by others to us, and a few other places (i.e. security
> reports), so we of course can't document the source of everything for
> obvious reasons.

Thanks for pointing me there but I do not think this is what I've had in
mind. I do understand that there is some pattern matching happening to
select most of the candidates, but as you've said this is then reviewed
and during that review you likely need to read through that changelog
and build some sort of statement why this is considered a security
threat.

I believe exactly _this_ would be a much more valuable information in
the CVE announcement than a copy&past of the changelog which on its own
can be trially referenced by a link. Also if there is a peer review
happening then Reviewed-by would be really nice. Not to mention
Reported-by if this was externally reported (the report could be a part
of the announcement as well).

Thanks!
-- 
Michal Hocko
SUSE Labs

Powered by blists - more mailing lists