Date: Fri, 24 May 2024 17:22:24 +0200
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: Michal Hocko <mhocko@...e.com>
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 Fri, May 24, 2024 at 04:02:18PM +0200, Michal Hocko wrote:
> On Fri 24-05-24 13:47:00, Greg KH wrote:
> > On Fri, May 24, 2024 at 12:10:56PM +0200, Michal Hocko wrote:
> > > 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:
> > > [...]
> > > > 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?
> > 
> > The documentation should say that you _SHOULD_ send proposals to
> > cve@...nel.org, did we get it wrong somehow?
> > 
> > > 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.
> > 
> > I'm confused as to what in that document is incorrect, care to point it
> > out?
> 
> Maybe I've just misunderstood the part about sending patches against
> cve/review/proposed/. I was thinking about sending pull requests against
> vulns.git.

Yes, you can do that too, send it to same email address.  That's not
really documented, just ask us instead!  :)

> > And people want to word-smith the text all the time already, so we just
> > default to using the changelog text as that's the most "neutral" and
> > public information out there (i.e. we don't have to worry about any sort
> > of data-retention or classification laws as the information is already
> > public in kernel changelog text.)
> 
> This part I do not understand. What is wrong about a reasoning why
> something has been considered a CVE? E.g. something like 
> CVE assigned because a potential WARN_ON is fixed and that could panic
> with panic_on_warn. Fixed by <URL_TO_LINUS_TREE>
> 
> or
> CVE assigned because UAF is fixed and those can be generally used to
> construct more complex attacks. Fixed by <URL_TO_LINUS_TREE>
> 
> etc.

Doing the work to classify all of these in this manner isn't going to
happen by us, sorry, as it is not required by the CVE process, and
frankly, we are doing a load of work already here.  We are going to rely
on the text that is in the changelog.  Maybe over time you can work with
the kernel developers to write better changelogs to describe what you
are looking for?

We will rely on external parties to "classify" the CVEs if they wish to
as there is already a whole ecosystem that attempts to do this already,
with various success.  In the end, it's up to each integrator of Linux
to classify them themselves as everyone's use case is different
(remember, cow milking machines, super-mega-yaht-stabilizers, washing
machines, servers, watches, air-traffic-control systems, etc...)

thanks,

greg k-h

Powered by blists - more mailing lists