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: <nycvar.YFH.7.76.2402271051480.21798@cbobk.fhfr.pm>
Date: Tue, 27 Feb 2024 10:53:43 +0100 (CET)
From: Jiri Kosina <jikos@...nel.org>
To: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
cc: Michal Hocko <mhocko@...e.com>, 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 Feb 2024, Greg Kroah-Hartman wrote:

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

Whatever the security threat model, whoever can offline memory by writing 
to this file can kill the machine already. So there is no *additional*
security issue fixed by this that'd justify a CVE.

-- 
Jiri Kosina
SUSE Labs