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

[Michal Hocko]

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