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
next prev parent reply other threads:[~2024-02-16 15:35 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-14 8:00 [PATCH v3] Documentation: Document the Linux Kernel CVE process 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 7:31 ` [RFC] doc headings sweep Vegard Nossum
2024-02-17 16:34 ` Randy Dunlap
2024-02-19 21:05 ` Jonathan Corbet
2024-02-17 11:56 ` [PATCH v3] Documentation: Document the Linux Kernel CVE process 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.