Received-SPF: pass (google.com: domain of linux-kernel+bounces-86460-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1;
Date: Thu, 29 Feb 2024 10:41:58 +0100
From: Michal Hocko <mhocko@suse.com>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Kees Cook <keescook@chromium.org>, cve@kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: CVE-2023-52451: powerpc/pseries/memhp: Fix access beyond end of
 drmem array
Message-ID: <ZeBRZqJd5HAKaOfC@tiehlicka>
References: <2024022257-CVE-2023-52451-7bdb@gregkh>
 <Zdylmz28rZ-mCeiN@tiehlicka>
 <2024022639-wronged-grafted-6777@gregkh>
 <ZdytVTOgfvKBBvtn@tiehlicka>
 <202402271029.FD67395@keescook>
 <Zd8hPpP_6q_o8uQW@tiehlicka>
 <202402280906.D6D5590DB@keescook>
 <ZeA-281OudkWBhd_@tiehlicka>
 <2024022915-dissuade-grandson-ebd4@gregkh>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <2024022915-dissuade-grandson-ebd4@gregkh>

On Thu 29-02-24 09:35:28, Greg KH wrote:
[...]
> How does taking 10 patches differ from taking 200 patches?  Your
> testing/infrastructure issues should be the same, right?

You would be right if there was a test of every/most of the applied
patches. Which is not the case. The testing is merely about nothing has
broken in an obvious way. I hope we can agree that more patches that are
taken the larger the risk is.

I would have a much higher confidence in stable patches if they were
properly reviewed in the context of the tree they are applied to. This
is not done for the vast majority of them though.  I simply do not trust
"it applies so it is OK(ish)" approach.

> And really, if you have the crazy requirement of "All CVEs must be
> applied" then perhaps that needs to be revisited?  You are dictating
> your business's processes to an external entity, is that wise?

I do not think we (Suse) have any policy like that. We do evaluate CVEs
and other fixes and make risk/benefit based decisions. This is a
demanding process to say the least but it has allowed for very stable
code base.

> And if
> it is wise, why are you not able to handle it today?  Making it simpler
> for you to consume these entries seems to be a better decision.  With
> the changes we have made, you should be able to automatically determine
> if you are affected or not, which is something that you did NOT have
> before, so this might just be able to be automated, right?

Not really. The most of those fixes already do have stable or Fixes tags
so automation doesn't really require CVE number. If anybody is
interested to follow fixes in general then all the proper metadata are
already there.

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

> Remember, we KNOW that people have been scraping our commit logs for
> these types of things and using them in attacks for years.  At least
> this way we are giving you a machine-parsable feed that gives you the
> opportunity to make your kernels more secure than they previously were.

They are going to do that whether you stick CVE on top or not.
 
> Why is that not a good thing?

Because the more dubious or outright bogus CVEs there are the less
meaningful they will become.

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.

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.
-- 
Michal Hocko
SUSE Labs