linux-kernel - Re: CVE-2023-52451: powerpc/pseries/memhp: Fix access beyond end of drmem array

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]

Message-ID: <202402280906.D6D5590DB@keescook>
Date: Wed, 28 Feb 2024 09:12:15 -0800
From: Kees Cook <keescook@...omium.org>
To: Michal Hocko <mhocko@...e.com>
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.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 Wed, Feb 28, 2024 at 01:04:14PM +0100, Michal Hocko wrote:
> On Tue 27-02-24 10:35:40, Kees Cook wrote:
> > On Mon, Feb 26, 2024 at 04:25:09PM +0100, Michal Hocko wrote:
> [...]
> > > Does that mean that any potentially incorrect input provided by an admin is
> > > considered CVE now?
> > 
> > Yes. Have you seen what USER_NS does? There isn't a way to know how
> > deployments are using Linux, and this is clearly a "weakness" as defined
> > by CVE. It is better to be over zealous than miss things.
> 
> If we are over zealous to the point when almost any fix is marked CVE
> then the special marking simply stops making any sense IMHO.

Perhaps, but the volume of fixes is high, and I think it's better to
over estimate than under estimate -- the work needed to actually
evaluate all these changes is huge: it's better to take everything from
-stable. 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.

> Are you confusing hardening with security relevant fixes here? It makes
> a lot of sense to reduce the attack space by sacrificing functionality
> for some usecases but in general a large part of the kernel is built
> around a "root can do anything" philosophy. Whether we like it or not.
> And that means that we do not even pretend to protect dubious
> configurations by root/CAP_SYSADMIN which could effectivelly DoS the
> system (just consider hotplug/hotremove as an example - try to run your
> workload when most CPUs or memory is offlined). Some operations are
> simply not suited for untrusted entity.

Sure, I understand, but it's not possible to prove the negative. Perhaps
this particular fix will never be used in an attack, but I don't think
it's good to underestimate the creativity of attackers chaining
unexpected states together.

> [...]
> 
> > There's no harm in marking fixes for weaknesses as CVEs, so why the
> > push back?
> 
> Because assigning CVEs nilly willy was the main downside of the prior
> process and I was hoping that the new one, in hands of kernel people,
> could be better and we could be getting more relevant CVEs.

The old assignment pattern was both radically below actual fixes
landing, and also regularly not applicable at all (CVEs for out-of-tree
downstream patches against Linux). On both counts, I think the new
process is better, even if it will produce some "very low" severity
CVEs. :)

-Kees

-- 
Kees Cook