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

[Michael Ellerman]

Michal Hocko <mhocko at suse.com> writes:
> [Let me add Michael as PPC maintainer - the thread starts with
> http://lkml.kernel.org/r/2024022257-CVE-2023-52451-7bdb@gregkh]

Sorry just saw this ...

> On Tue 27-02-24 06:14:45, Greg KH wrote:
>> On Mon, Feb 26, 2024 at 05:36:57PM +0100, Michal Hocko wrote:
> [...]
>> > All that being said I dispute the issue fixed here has any more security
>> > relevance than allowing untrusted user to control memory hotplug which
>> > could easily result in DoS of the system.
>> 
>> Ok, I traced this call back, and here is the callpath, starting with a
>> write to the the 'dlpar' sysfs file (conviently NOT documented in
>> Documentation/ABI, and it looks like it violates the "one value per
>> file" rule...)
>> 	dlpar_store()
>> 	handle_dlpar_errorlog()
>> 	dlpar_memory()
>> 	dlpar_memory_remove_by_index()
>> 
>> Yes, the kernel by default sets 'dlpar' to 0644, BUT that means that
>> root in a container can cause this use-after-free to happen, or if the
>> permissions are changed by userspace, or if you are in "lockdown mode",
>> or if you want to attempt the crazy "confidential computing" model, or
>> if you have a system which root is possible for some things by normal
>> users (there are lots of different security models out there...)
>
> This is all nice but please do realize that if you allow access to to
> memory hotremove to any untrusted entity (be it a root in container or
> by changing access permissions) then the machine is in a serious
> resource management control trouble already and that is a security
> threat already.

The standard container runtimes, eg. podman/docker, will mount /sys as
read-only by default. So at least in typical situations root in a
container will not be able to trigger this issue.

>> Yes, I will argue that making the sysfs file writable by userspace is
>> out of our control, but what is in our control is the fact that there is
>> a out-of-bounds write that is fixed here, and we don't want those to be
>> able to be triggered by anyone as that is a weakness in our codebase.
>
> Yes, and that is why the fix is good and nobody disputes that. What I am
> actually trying to drill down to is whether this is an actual security
> threat worth assigning a CVE or it is just yet-anothing-pointless-CVE we
> were so used to with the old process.
>
>> That is what has caused the CVE to be created here, not the fact that
>> root can remove memory as that's the normal expected operation to have
>> happen here.
>>
>> However if the maintainer of the code here disputes this, we are more
>> than willing to mark this invalid and reject the CVE.
>
> Michael, do you see any real security risk being addressed by
> bd68ffce69f6 ("powerpc/pseries/memhp: Fix access beyond end of drmem
> array").

No I don't think this bug on its own is a "real" security risk.

It allows root to print 8 bytes of kernel memory it's not supposed to,
but there's no way for the attacker to control what 8 bytes. So I doubt
that's actually useful for constructing an exploit.

But as Kees explained elsewhere, a CVE can be for any weakness, not just
actual vulnerabilties.

So under that definition I'm quite happy for this to be given a CVE.

cheers