Re: ACPICA: acpi: acpica: fix acpi operand cache leak in nseval.c

[Greg KH <gregkh@linuxfoundation.org>]

On Thu, May 10, 2018 at 06:45:42PM +0000, Schmauss, Erik wrote:
> 
> > -----Original Message-----
> > From: Greg KH [mailto:gregkh@linuxfoundation.org]
> > Sent: Wednesday, May 9, 2018 11:55 PM
> > To: Mark Salyzyn <salyzyn@android.com>
> > Cc: stable <stable@vger.kernel.org>; Seunghun Han <kkamagui@gmail.com>;
> > Schmauss, Erik <erik.schmauss@intel.com>; Wysocki, Rafael J
> > <rafael.j.wysocki@intel.com>; kernel-team <kernel-team@android.com>
> > Subject: Re: ACPICA: acpi: acpica: fix acpi operand cache leak in nseval.c
> > 
> > On Wed, May 09, 2018 at 02:30:14PM -0700, Mark Salyzyn wrote:
> > > ToT commit 97f3c0a4b0579b646b6b10ae5a3d59f0441cc12c
> > 
> > "ToT"?  What does that mean?
> > 
> > >
> > > (ACPICA: acpi: acpica: fix acpi operand cache leak in nseval.c)
> > >
> > > was assigned CVE-2017-13695
> > > https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-13695
> > > and has been public since August 25 2017
> > >
> > > Please apply to 3.18, 4.4 and 4.9 stable kernels for the reasons
> > > outlined in the body of the patch:
> > >
> > > "This cache leak causes a security threat because an old kernel (<=
> > > 4.9) shows memory locations of kernel functions in stack dump. Some
> > > malicious users could use this information to neutralize kernel ASLR."
> > >
> > > Bonus Points: Since the patch is ToT upstream, relieving the bug that
> > > results in the memory leak, even despite the non-CVE security status
> > > for
> > > <=4.12 kernels, it may be advised to also include this patch in 4.14.y
> > > stable as well.
> > 
> > Well, I wouldn't apply a patch to just older kernels and not newer ones, that just
> > causes confusion.
> > 
> > But I'm going to push back on this.  The kernel security team said something like
> > "this is crazy, if you control ACPI tables you have bigger problems" when this bug
> > was reported and told the developer to just submit this as a normal code
> > cleanup.
> > 
> > Granting this a CVE was, in my opinion, a total mistake as well.  This doesn't fix
> > any "real" problem that anyone can hit in the wild from what I can tell.  And
> > again, if you can modify ACPI tables, there are much bigger problems you can
> > cause on the hardware.
> 
> Agreed. Could we somehow close this CVE?

Please do, you can submit a request for it to be rejected on the main
CVE site somewhere.  I've done it once in the past.

> > Because of this, why would you need/want this in the stable kernel releases?  It
> > doesn't fix any real bug, only a theoretical one, right?
> 
> The AML would need to be carefully crafted. So yes, this could happen in theory.
> 
> > 
> > ACPI developers, do you think this should be backported?
> 
> One reason to backport this patch is that it performs memory reclamation for
> certain code paths. So no, not necessary but it might be a nice-to-have.

Nice to have for what?  If the AML is correct (as all devices have), all
should be fine, right?

thanks,

greg k-h