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]

Date: Wed, 28 Feb 2024 13:04:14 +0100
From: Michal Hocko <mhocko@...e.com>
To: Kees Cook <keescook@...omium.org>
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 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.

> > I guess we would need to ban interfaces like /dev/mem and many others.
> 
> Yes. Absolutely. :) Have you seen CONFIG_STRICT_DEVMEM,
> CONFIG_IO_STRICT_DEVMEM, etc? Many deployments keep a bright line
> between root and kernel. There is a whole subsystem (lockdown) for
> working to enforce this.

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.

[...]

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