Re: [PATCH v3] Documentation: Document the Linux Kernel CVE process

[Michal Hocko <mhocko@suse.com>]

On Fri 16-02-24 16:34:57, Greg KH wrote:
> 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.

Right, generally speaking this is not an easy task. It requires a lot of
diligence actually. Sometimes there is no clear cut and that is _fine_.
The CVE system cannot ever be bullet proof and mark every single
security related fix (really you can be creating new security problems
just by backporting upstream fixes into stable trees).

But that is not really all that important, the main thing/question is
whether it can be _useful_. If you simply assign CVE to any fix in
stable you end up with thousands of CVEs and I really fail to see any
practical benefit from that. Well, unless you want to DoS the system and
its consumers. Who do you expect to be the user/consumer of those CVE
numbers? You have already said that community supported stable kernels
mandate the latest version to be used. Those users do not need to know
there is $BIG_NUMBER of CVEs in them.

If you want to mark a specific class of fixes with CVE because they are
known to be used for exploits then fine! That is something actually
useful. If you allow users to explicitly mark a fix as security relevant
because of XYZ argument then really great!

> 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.

I am completely with you on that! That is quite far away from what the
documentation says AFAICS.
 
> 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.

I've been through that exercise with the CVE process over years many
times. It has always been a pain because you were not talking to domain
experts who could evaluate the reasoning behind the dispute. I consider
the new process of a clearly defined dispute process a big improvement!
But if the real practice would be thousands of CVEs created for any
stable backport then this will DoS many existing CVE consumers.

All that being said. I do agree that taking control of CVEs and making
that kernel community thing is a good thing! But I really fail to
understand how increasing the number of CVEs by nominating all/most
stable fixes is going to help anybody or improve the existing process.

Thanks!
-- 
Michal Hocko
SUSE Labs