linux-kernel - Re: CVE-2021-46966: ACPI: custom_method: fix potential use-after-free issue

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <2024022951-worst-relatable-f4bb@gregkh>
Date: Thu, 29 Feb 2024 09:40:08 +0100
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: Michal Hocko <mhocko@...e.com>
Cc: cve@...nel.org, linux-kernel@...r.kernel.org
Subject: Re: CVE-2021-46966: ACPI: custom_method: fix potential
 use-after-free issue

On Thu, Feb 29, 2024 at 09:30:12AM +0100, Michal Hocko wrote:
> On Thu 29-02-24 06:22:34, Greg KH wrote:
> > On Wed, Feb 28, 2024 at 05:14:22PM +0100, Michal Hocko wrote:
> > > Hi,
> > > this seems like another example of a reasonable fix with a very dubious
> > > CVE IMHO. Allowing access to /sys/kernel/debug/acpi/custom_method to
> > > anybody but trusted actor is a huge security problem on its own. I
> > > really fail to see any value marking this clear bug fix as security
> > > related.
> > 
> > It was picked because it was a use-after-free fix, AND it is part of the
> > "import the GSD database into the CVE database" that the CVE project
> > asked us to do.
> 
> OK I see. So now, does it make any sense to consider a bug fix in a
> security sensitive interface (that is even locked down) a security fix?

Yes, I would think so!  If you see any that we have not marked for a
CVE, please let us know and we will be glad to assign them.

Again, we do not always know if things are "locked down" or not, as
everyone uses our codebase in different ways (we don't have the benefit
of a *BSD which does dictate the use cases in ways we can not).

If your systems "lock this down" and prevent access to anyone you do not
trust, then wonderful, you aren't vulnerable to this specific issue at
all and you can just ignore it!

But for other systems that DO allow access to debugfs, this might be a
good idea to address.

thanks,

greg k-h