On Thu, May 10, 2018 at 06:45:42PM +0000, Schmauss, Erik wrote: > > > -----Original Message----- > > From: Greg KH [mailto:gregkh@xxxxxxxxxxxxxxxxxxx] > > Sent: Wednesday, May 9, 2018 11:55 PM > > To: Mark Salyzyn <salyzyn@xxxxxxxxxxx> > > Cc: stable <stable@xxxxxxxxxxxxxxx>; Seunghun Han <kkamagui@xxxxxxxxx>; > > Schmauss, Erik <erik.schmauss@xxxxxxxxx>; Wysocki, Rafael J > > <rafael.j.wysocki@xxxxxxxxx>; kernel-team <kernel-team@xxxxxxxxxxx> > > 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