Received-SPF: pass (google.com: domain of linux-kernel+bounces-68887-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99;
Date: Fri, 16 Feb 2024 16:34:57 +0100
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Michal Hocko <mhocko@suse.com>
Cc: corbet@lwn.net, workflows@vger.kernel.org, linux-doc@vger.kernel.org,
	linux-kernel@vger.kernel.org, security@kernel.org,
	Kees Cook <keescook@chromium.org>, Sasha Levin <sashal@kernel.org>,
	Lee Jones <lee@kernel.org>
Subject: Re: [PATCH v3] Documentation: Document the Linux Kernel CVE process
Message-ID: <2024021620-retrieval-lethargic-eeca@gregkh>
References: <2024021430-blanching-spotter-c7c8@gregkh>
 <Zc5PycMenLBYECAn@tiehlicka>
 <2024021518-stature-frightful-e7fc@gregkh>
 <Zc5ZpB6jsuTKmhv5@tiehlicka>
 <2024021646-procedure-faceted-ea87@gregkh>
 <Zc9hBJuca3f_5KHx@tiehlicka>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Zc9hBJuca3f_5KHx@tiehlicka>

On Fri, Feb 16, 2024 at 02:20:04PM +0100, Michal Hocko wrote:
> > Right now
> > we are fixing lots and lots of things and no one notices as their
> > "traditional" path of only looking at CVEs for the kernel is totally
> > incorrect.
> 
> Right, there are quite a lot of people who consider CVE fixes much more
> important than regular fixes. Their reasoning might be completely
> misleading but there might be very good reasons to stick to minimalistic
> approach, e.g. to reduce risk of regressions.
> 
> I believe it is perfectly fair to say that whoever relies on stable
> kernels support needs to update to the latest stable kernel version to
> be covered by security and functional fixes. On the other hand I do not
> think it is an improvement to the process to swamp CVE database with any
> random fixes without a proper evaluation. If the kernel community
> doesn't believe in the CVE process then fair enough, just do not assign
> them unless you want to explicitly call out fixes with a high impact
> security implications. Having fewer good quality CVEs would definitely
> improve the process.

As you know, it's almost impossible to determine if a fix is "high
impact" or not, given that we have no idea what anyone's use case is for
the kernel.  We have documented proof of single-byte-buffer-overflows
resulting in complete system takeovers, and the same for very tiny
use-after-free issues, and the same for tiny "overflow a USB string
buffer" issues, and so on.

So as always, we need to treat "a bug is a bug is a bug" and when
looking at the bug fix, if it resolves something that is known to be
a vulnerability (again, as defined by CVE themselves), then we need to
mark it as such.

If you find that we are marking things as a CVE thatt you do not feel
should be marked as such, please let us know and we will be glad to
discuss it on a case-by-case basis.

But note, this type of classification has been happening for the kernel
stable commits for 2+ years now, by Sasha, in the GSD records, so this
isn't something new that we have been doing, it's just that only a very
small group were noticing that, and now a larger one might notice this.

thanks,

greg k-h