linux-kernel - Re: CVE-2023-52734: net: sched: sch: Bounds check priority

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Wed, 29 May 2024 11:51:10 +0200
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: Michal Hocko <mhocko@...e.com>
Cc: cve@...nel.org, linux-kernel@...r.kernel.org,
	linux-cve-announce@...r.kernel.org,
	Kees Cook <keescook@...omium.org>
Subject: Re: CVE-2023-52734: net: sched: sch: Bounds check priority

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