Message-ID: <2024021459-trimness-bolt-7185@gregkh>
Date: Wed, 14 Feb 2024 14:58:29 +0100
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: Jiri Kosina <jikos@...nel.org>
Cc: corbet@....net, workflows@...r.kernel.org, linux-doc@...r.kernel.org,
	linux-kernel@...r.kernel.org, security@...nel.org,
	Kees Cook <keescook@...omium.org>, Sasha Levin <sashal@...nel.org>,
	Lee Jones <lee@...nel.org>
Subject: Re: [PATCH v3] Documentation: Document the Linux Kernel CVE process

On Wed, Feb 14, 2024 at 02:43:48PM +0100, Jiri Kosina wrote:
> On Wed, 14 Feb 2024, Greg Kroah-Hartman wrote:
> 
> > +No CVEs will be automatically assigned for unfixed security issues in
> > +the Linux kernel; assignment will only automatically happen after a fix
> > +is available and applied to a stable kernel tree, and it will be tracked
> > +that way by the git commit id of the original fix. 
> 
> I think this needs way more clarification .. how exactly is this going to 
> work?
> 
> Do I read this correctly that *everything* that lands in -stable will 
> automatically get CVE assigned? If so, that's just plain crazy. Just took 
> a random peek on the topmost -stable changelog ...
> 
> 	ASoC: codecs: wsa883x: fix PA volume control
> 	ASoC: codecs: lpass-wsa-macro: fix compander volume hack
> 	ASoC: codecs: wcd938x: fix headphones volume controls
> 	ASoC: qcom: sc8280xp: limit speaker volumes
> 	drm/amdgpu: Fix missing error code in 'gmc_v6/7/8/9_0_hw_init()'
> 
> Only the last one can *potentially* be considered a CVE candidate, but 
> someone would actually have to take a *deep* look. Most likely it'll be a 
> functional issue, but not a security issue by any measures.
> 
> So I hope it's not the case, and someone will actually be doing some 
> triage. If that's the case -- is this process described anywhere?

It's described as "we know it when we see it" :)

Seriously, this is something that Sasha has already been doing
successfully for 3+ years now with the GSD project, so look at the
commits that have been assigned there for an example of what will be
picked.  Also we will probably go back in time for a few years and use
that data to populate the CVE database for older releases as long as
they are still in currently supported releases as this is something that
the CVE group has asked us to do already.

As for your list above, I doubt any of those would be a CVE, give us
some credit here.  Let's see how it goes and if people complain we are
picking things that we shouldn't be picking, OR if we aren't picking
enough, they will then be asked to join the team doing the work :)

The people that make up the current team, Lee, Sasha, and I, have a LONG
history of fixing and triaging and managing security bugs for the
kernel, in the community and in corporate environments.  We know how to
do this as we have been doing it for decades already.  If you or anyone
else wishes to help us out with this classification, we can gladly use
the help.

> Also, how are the CVSS-like scores going to be assigned? There are no 
> details whatsoever about that in the document.

We will not be doing any CVSS scoring as that is outside the scope of a
CVE entry and not required at all, and the CVE board agrees with this
decision.  As you well know, doing something like this for the kernel
where we have no idea what your use case is, is almost impossible on the
best days.

There are external groups that suck in the CVE entries and attempt to
assign CVSS-like scores to issues.  It will be "interesting" to see how
they classify things, but if the history of how well they have done this
in the past is any indication, their tools need a lot of work and
hopefully people stop relying on them and do the evaluation of their own
use cases instead.

> In any case, by making this change we are going to make security theathre 
> industry super-happy (they will have a lot of expensive nothing going on), 
> and all the distros not basing on -stable very unhappy (we're already 
> drowning because everybody and his grandma wants to become famous by 
> publishing a CVE for something completely irrelevant). If this is the 
> intention, it should be spelled out loud and clear.

As we are not allowed to credit anyone in the publication of a CVE, I
doubt the "I want a CVE!" group will get any louder than they currently
are.  And if it generates these people to actually submit bug fixes with
their reports, all the better for us!

I can't speak to the "security theatre industry" but right now, we have
a real problem of external groups assigning random CVEs to the kernel
with absolutely no input from us and no accountability, which is causing
a lot of us real problems.  This will take away the ability for those
groups to continue to abuse our project just because of their broken
engineering rules, and properly integrate them into our development
process if they so desire to join in.

thanks,

greg k-h

Powered by blists - more mailing lists