From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.kernel.org ([198.145.29.99]:40718 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750758AbeEKFYh (ORCPT ); Fri, 11 May 2018 01:24:37 -0400 Date: Fri, 11 May 2018 07:23:55 +0200 From: Greg KH To: "Schmauss, Erik" Cc: Mark Salyzyn , "Moore, Robert" , stable , Seunghun Han , "Wysocki, Rafael J" , kernel-team Subject: Re: ACPICA: acpi: acpica: fix acpi operand cache leak in nseval.c Message-ID: <20180511052355.GA2902@kroah.com> References: <7ee79f5f-22dd-e637-1414-76e3d0715c4a@android.com> <20180510065519.GC25873@kroah.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: stable-owner@vger.kernel.org List-ID: 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 > > Cc: stable ; Seunghun Han ; > > Schmauss, Erik ; Wysocki, Rafael J > > ; kernel-team > > 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