workflows.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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
Date: Fri, 16 Feb 2024 16:34:57 +0100	[thread overview]
Message-ID: <2024021620-retrieval-lethargic-eeca@gregkh> (raw)
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

  reply	other threads:[~2024-02-16 15:35 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-14  8:00 Greg Kroah-Hartman
2024-02-14  8:34 ` Lukas Bulwahn
2024-02-15 12:04   ` Greg Kroah-Hartman
2024-02-15 16:10     ` Oleksandr Natalenko
2024-02-15 17:49       ` Greg Kroah-Hartman
2024-02-14  8:37 ` Vegard Nossum
2024-02-15 11:50   ` Greg Kroah-Hartman
2024-02-15 12:24     ` Vegard Nossum
2024-02-16  8:28       ` Jani Nikula
2024-02-16 11:22         ` Greg Kroah-Hartman
2024-02-16 14:58           ` Jonathan Corbet
2024-02-17 11:56             ` Greg Kroah-Hartman
2024-02-14 13:10 ` Krzysztof Kozlowski
2024-02-15 12:00   ` Greg Kroah-Hartman
2024-02-14 13:41 ` Konstantin Ryabitsev
2024-02-15 11:59   ` Greg Kroah-Hartman
2024-02-14 13:43 ` Jiri Kosina
2024-02-14 13:55   ` Mark Brown
2024-02-14 14:32     ` Greg Kroah-Hartman
2024-02-14 14:46     ` Jiri Kosina
2024-02-14 15:10       ` Mark Brown
2024-02-14 13:58   ` Greg Kroah-Hartman
2024-02-14 14:38     ` Jiri Kosina
2024-02-14 15:09       ` Greg Kroah-Hartman
2024-02-15  8:17 ` Thorsten Leemhuis
2024-02-15  8:43   ` Greg Kroah-Hartman
2024-02-15 17:54 ` Michal Hocko
2024-02-15 18:20   ` Greg Kroah-Hartman
2024-02-15 18:36     ` Michal Hocko
2024-02-16 11:25       ` Greg Kroah-Hartman
2024-02-16 13:20         ` Michal Hocko
2024-02-16 15:34           ` Greg Kroah-Hartman [this message]
2024-02-16 16:51             ` Michal Hocko
2024-02-15 19:40     ` Kees Cook
2024-02-16  7:41       ` Greg Kroah-Hartman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2024021620-retrieval-lethargic-eeca@gregkh \
    --to=gregkh@linuxfoundation.org \
    --cc=corbet@lwn.net \
    --cc=keescook@chromium.org \
    --cc=lee@kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mhocko@suse.com \
    --cc=sashal@kernel.org \
    --cc=security@kernel.org \
    --cc=workflows@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox