Message-ID: <2024022913-borrower-resource-ecc9@gregkh>
Date: Thu, 29 Feb 2024 15:18:36 +0100
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: Michal Hocko <mhocko@...e.com>
Cc: Kees Cook <keescook@...omium.org>, cve@...nel.org,
	linux-kernel@...r.kernel.org
Subject: Re: CVE-2023-52451: powerpc/pseries/memhp: Fix access beyond end of
 drmem array

On Thu, Feb 29, 2024 at 10:41:58AM +0100, Michal Hocko wrote:
> > > > This has been a long standing problem with communicating this
> > > > to engineering management in many organizations. They have pointed to
> > > > the relatively small number of CVEs and said, "just backport those
> > > > fixes", and trying to explain that it's is totally insufficient falls on
> > > > deaf ears.
> > > 
> > > I think it is fair to say/expect that every downstream is responsibile
> > > for the kernel they are distributing and that applies to vulnerabilities
> > > affecting those kernels. Forcing fixes by slapping CVE over them sounds
> > > just very dubious to me.
> > 
> > Not having CVEs assigned for things that can cause issues is dubious,
> > which is why we are doing this.  We can not determine use cases of our
> > code base, that is up to you as a distro to figure out, all we can do is
> > our best to call out "This might be something you want to take!" which
> > is what we are doing here.
> 
> You are missing my point I am afraid. Downstreams do not need CVE numbers
> to fish for useful fixes. Downstreams, however, would appreciate the call
> out serious security problems to treat them with higher priority because
> believe me it makes a huge difference to address an exploitable problem
> promptly rather than one that is affecting a misconfigured system which
> is by definition vulnerable. And while I am sympathetic with your "we
> cannot assume usecases" statement, I believe we can still tell a
> difference that some configurations simply make no sense from the
> security perspective.

The reason we became a CNA is NOT because we want to only call out "high
priority" issues, because obviously, we can not do that as we do not
know anyone's use case and we can not claim any specific user is higher
priority than another.

The reason we DID become a CNA was because there were entities out there
filing CVEs against invalid stuff AND causing problems for everyone,
including the kernel developers themselves, and making it impossible to
ever get anything revoked no matter how wrong they were.

As part of the requirement to be a CNA, we have to announce everything
that we think is a potential vulnerability, severity not be judged at
all as that is NOT part of the CVE project or program.  It is up to
others to judge the severity, not us, nor the CVE group themselves,
that's not what the ID is for.

So, because of this, we are now assigning CVE ids to everything that we
review that we think is a vulnerability AND everything that people
submit to us to have a CVE assigned to that they deem is a
vulnerability.  Many groups/people have already asked us for IDs and we
have only turned one down so far (the submitter agreed that it wasn't an
issue at all).

We also are required to go back through the GSD entries and create CVE
entries for them as well, which is why you are seeing these "older"
entries be created.  We have many thousands to go through of them, so
that will take us a while to catch up (next few months.)

Again, none of this has anything to do with "severity", it only is an
identifier that says "this fixes a vulnerability".

> > Why is that not a good thing?
> 
> Because the more dubious or outright bogus CVEs there are the less
> meaningful they will become.

That's not our problem or issue.  All we care about is properly tagging
things we see as fixes for vulnerabilities.  Other groups can judge the
"meaning of what a CVE is or not".

> Look, it seems there is a huge gap in our understanding of what the CVE
> is good for. I was really hopeful that the noise/signal ratio would be
> better with the new model but that doesn't seem to be the case so far. I
> was also hoped that the dispute process would be improved but judging
> from the discussion so far I have lost that hope as well.

It's better than the old process where you could NOT even dispute a CVE
and get it rejected at all, don't you think?  We've already rejected a
few, probably more than has ever been rejected for the kernel in the
past few years.

We are working this out as we go, if you can come up with ways to make
this easier for everyone involved, we are more than willing to work on
it.  But note, it's only been a week!  Give us a chance please.

And the signal/noise all depends on your use case.  Again, we can not
judge that.

> Please asked yourself again who is going to benefit from this. Stable
> users certainly not, because they are supposed to use the latest stable
> kernels so all the fixes (no matter of CVE), downstreams based on stable
> kernels will not benefit either because of the same reason. Downstreams
> which are not based on stable trees will not benefit either because of
> the low signal/noise ratio and will need to find a better way to find
> important and safe fixes. Probably the only winner will be those fancy
> CVE scanners which will have more to scan.

The overall community is going to benifit because more actual fixes will
be picked up by the distros that today are not picking them up.  It's
pretty trivial to get root on most of the "enterprise" kernels today,
and on many phones, because people are NOT picking the stable releases.
I do a presentation every year at a major phone company where I show how
easy it is to break their device just because they keep insisting that
they "know" what commits to take from the stable kernels.  They have
finally changed their minds and will be taking stable updates, and I
hope the enterprise kernels will as well.

But again, that's independent of the CVE process.  We have taken it over
because what was there was broken and abused by many bad actors.  And
again, we are now required to report as many issues as we notice, which
is what we are doing.  We will get some wrong over time, but overall, I
only see complaints about 2-3 when we have already issued:
	Number of assigned CVE ids, by year:
		2019:	   2
		2020:	  13
		2021:	 147
		2022:	   1
		2023:	  51
		2024:	  26
		Total:	 240
240 as of right now, and haven't really started the process of issuing
ids for the current stable tree (i.e. 6.7.x).

thanks,

greg k-h

Powered by blists - more mailing lists