All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Michal Hocko <mhocko@suse.com>
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: Wed, 29 May 2024 11:51:10 +0200	[thread overview]
Message-ID: <2024052930-dealt-class-f845@gregkh> (raw)
In-Reply-To: <ZlbIZ8bdBK4tZcBa@tiehlicka>

On Wed, May 29, 2024 at 09:30:08AM +0200, Michal Hocko wrote:
> On Tue 28-05-24 21:06:39, Greg KH wrote:
> > On Tue, May 28, 2024 at 09:53:12AM +0200, Michal Hocko wrote:
> > > Is this really soemthing that should be getting a CVE assigned?
> > > First the fix is incomplete - 9cec2aaffe96 ("net: sched: sch: Fix off by one in htb_activate_prios()")
> > 
> > Incomplete fixes are still part of a fix :)
> 
> Sigh
> 
> > > Second is this even real problem? https://lore.kernel.org/all/Y9V3mBmLUcrEdrTV@pop-os.localdomain/
> > > suggests it is not.
> > 
> > Ah, good catch, I didn't see that.  I'll go revoke this as it's not
> > doing anything.
> 
> Thanks!
> 
> I wish the CVE review process would catch something like that before
> issuing a CVE for it.

I too want a pony :)

> > > And third, WARN_ONs are considered a real deal by CVE team because
> > > somebody might be running with panic_on_warn. This patch adds one!
> > 
> > Yes, but if you can't hit that by anything from userspace, it's not an
> > issue and just dead code.  We'll have to wait for a future syzbot report
> > to prove that wrong :)
> 
> I am not judging the patch itself. It is maintainers who should decide
> whether this is something they want to accept.
> 
> 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.  It was
in a batch where I reviewed 124 entries at once, 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.

Yes, I will get things wrong on the GSD backfill, and I am re-reviewing
them all, which is honestly, something that MITRE did NOT ask us to do,
but I am doing just because of minor things like this where perhaps the
entry should not have been made in the past.  And as part of that
review, yes, I have found some other entries that didn't deserve a CVE,
and so didn't create them.  If you would like me to just do a simple
"import them all without an additional review", I will be glad to do so
as it would be much easier and save me loads of time.

I welcome others to help out with this work, including yourself, if you
so desire.  That would help out a lot.

thanks,

greg k-h

  reply	other threads:[~2024-05-29  9:51 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-05-21 15:23 CVE-2023-52734: net: sched: sch: Bounds check priority Greg Kroah-Hartman
2024-05-28  7:53 ` 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 [this message]
2024-06-06  7:24         ` Michal Hocko

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=2024052930-dealt-class-f845@gregkh \
    --to=gregkh@linuxfoundation.org \
    --cc=cve@kernel.org \
    --cc=keescook@chromium.org \
    --cc=linux-cve-announce@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mhocko@suse.com \
    /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.