Received-SPF: pass (google.com: domain of linux-kernel+bounces-81873-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99;
Date: Mon, 26 Feb 2024 17:12:19 +0100
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Michal Hocko <mhocko@suse.com>
Cc: 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: <2024022652-defective-fretful-3d13@gregkh>
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? I guess we would need to ban interfaces like
> /dev/mem and many others.

If you have your system set up to prevent admins from accessing /dev/mem
(isn't there a config option for that), and you can access it, then yes,
that would be a CVE-worthy issue.

But if you configure your system to allow an admin access to /dev/mem
then you wanted that :)

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

We can not determine threat models when filing CVEs as we do not know
what your threat model is.  All we can do is determine if this resolves
a weakness in the system.  A use-after-free is a weakness and this
resolves that issue.

It is up to others to "grade" the CVEs if they want to.  There are loads
of other orginizations that do that type of thing, taking into
consideration specific threat models by which they wish to enforce.  If
your orginization thinks this is not relevent to your threat model at
all, wonderful, you can ignore it :)

thanks,

greg k-h