From: Michal Hocko <mhocko@suse.com>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: cve@kernel.org, linux-kernel@vger.kernel.org,
linux-cve-announce@vger.kernel.org,
Kees Cook <keescook@chromium.org>
Subject: Re: CVE-2023-52734: net: sched: sch: Bounds check priority
Date: Thu, 6 Jun 2024 09:24:09 +0200 [thread overview]
Message-ID: <ZmFkGWitjXvyOtbK@tiehlicka> (raw)
In-Reply-To: <2024052930-dealt-class-f845@gregkh>
On Wed 29-05-24 11:51:10, Greg KH wrote:
> On Wed, May 29, 2024 at 09:30:08AM +0200, Michal Hocko wrote:
[...]
> > I am questioning the decision to make it a CVE. Because if that was a
> > real deal then WARN_ON is something kernel CNA is considering a CVE worth
> > problem! So a CVE has been filed with a fix that is CVE itself.
> > Seriously how could this pass through the CVE review process?
>
> "How" is "this was part of the entries in the GSD records that MITRE
> asked us to back-fill as CVE entries". Those entries already went
> through two different rounds of review last year for the GSD record, and
> I did another one as well now before the CVE creation happened.
I am sorry but I have no idea how that is supposed to justify assigning
a CVE to a non-issue with a fix that is clearly considered a CVE on its
own. An overlook, sure. That is understandable but the above doesn't
make any sense to me.
> It was in a batch where I reviewed 124 entries at once,
OK, this makes much more sense and I do not mean to blame you for
overlooking a particular things. But ...
> and if I only got one
> wrong, hey, that's a very good % overall, don't you think? Especially
> as it has been a publicily listed "vulnerability fix" for well over a
> year now in the GSD system, and no one objected to it there.
... it is unavoidable to overlook completely bogus or even harmfull CVE
fixes if they are generated in the current volumes. It is much worse
that it is easier to overlook those which really are important.
Especially during CVSS assessment. This simply cannot scale!
[...]
> I welcome others to help out with this work, including yourself, if you
> so desire. That would help out a lot.
I am sorry but I fundamentally disagree with the way how CVEs are
processed _now_ and therefore I will not put my name under that. I am
still hopeful that this is just the new process finding its own way and
it will settle on something much more reasonable and _useful_.
--
Michal Hocko
SUSE Labs
prev parent reply other threads:[~2024-06-06 7:24 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <2024052100-CVE-2023-52734-c8c2@gregkh>
2024-05-28 7:53 ` CVE-2023-52734: net: sched: sch: Bounds check priority Michal Hocko
2024-05-28 19:06 ` Greg Kroah-Hartman
2024-05-29 7:30 ` Michal Hocko
2024-05-29 9:51 ` Greg Kroah-Hartman
2024-06-06 7:24 ` Michal Hocko [this message]
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=ZmFkGWitjXvyOtbK@tiehlicka \
--to=mhocko@suse.com \
--cc=cve@kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=keescook@chromium.org \
--cc=linux-cve-announce@vger.kernel.org \
--cc=linux-kernel@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