Received-SPF: pass (google.com: domain of linux-kernel+bounces-83848-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249;
Date: Tue, 27 Feb 2024 10:35:40 -0800
From: Kees Cook <keescook@chromium.org>
To: Michal Hocko <mhocko@suse.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.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: <202402271029.FD67395@keescook>
References: <2024022257-CVE-2023-52451-7bdb@gregkh>
 <Zdylmz28rZ-mCeiN@tiehlicka>
 <2024022639-wronged-grafted-6777@gregkh>
 <ZdytVTOgfvKBBvtn@tiehlicka>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <ZdytVTOgfvKBBvtn@tiehlicka>

On Mon, Feb 26, 2024 at 04:25:09PM +0100, Michal Hocko wrote:
> On Mon 26-02-24 16:06:51, Greg KH wrote:
> > On Mon, Feb 26, 2024 at 03:52:11PM +0100, Michal Hocko wrote:
> > > On Thu 22-02-24 17:21:58, Greg KH wrote:
> > > > Description
> > > > ===========
> > > > 
> > > > In the Linux kernel, the following vulnerability has been resolved:
> > > > 
> > > > powerpc/pseries/memhp: Fix access beyond end of drmem array
> > > > 
> > > > dlpar_memory_remove_by_index() may access beyond the bounds of the
> > > > drmem lmb array when the LMB lookup fails to match an entry with the
> > > > given DRC index. When the search fails, the cursor is left pointing to
> > > > &drmem_info->lmbs[drmem_info->n_lmbs], which is one element past the
> > > > last valid entry in the array. The debug message at the end of the
> > > > function then dereferences this pointer:
> > > > 
> > > >         pr_debug("Failed to hot-remove memory at %llx\n",
> > > >                  lmb->base_addr);
> > > 
> > > While this is a reasonable fix and the stable material it is really
> > > unclear to me why it has gained a CVE. Memory hotplug is a privileged
> > > operation. Could you clarify please?
> > 
> > As you know, history has shown us that accessing out of your allocated
> > memory can cause problems, and we can not assume use-cases, as we don't
> > know how everyone uses our codebase, so marking places where we fix
> > out-of-bound memory accesses is resolving a weakness in the codebase,
> > hence a CVE assignment.
> 
> 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.

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

> > If your systems are not vulnerable to this specific issue, wonderful, no
> > need to take it, but why wouldn't you want to take a fix that resolves a
> > known weakness?
> 
> I have explicitly said, the fix is reasonable. I just do not see a point
> to mark it as CVE. I fail to see any thread model where this would
> matter as it would require untrusted privileged actor to trigger it
> AFAICS. I am happy to be proven wrong here.

Given that weaknesses are commonly chained together for exploits, it's
just not possible to say something can never be used in an attack.
Exploits are about slowly gaining more and more leverage on a system,
expanding the scope of control a little more with each step.

It's not possible to make these distinctions without deep reachability
analysis and an omniscient view of all Linux deployments.

There's no harm in marking fixes for weaknesses as CVEs, so why the
push back?

-Kees

-- 
Kees Cook