All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <gregkh@linuxfoundation.org>
To: Mark Salyzyn <salyzyn@android.com>
Cc: stable <stable@vger.kernel.org>,
	Seunghun Han <kkamagui@gmail.com>,
	Erik Schmauss <erik.schmauss@intel.com>,
	"Rafael J. Wysocki" <rafael.j.wysocki@intel.com>,
	kernel-team <kernel-team@android.com>
Subject: Re: ACPICA: acpi: acpica: fix acpi operand cache leak in nseval.c
Date: Thu, 10 May 2018 08:55:19 +0200	[thread overview]
Message-ID: <20180510065519.GC25873@kroah.com> (raw)
In-Reply-To: <7ee79f5f-22dd-e637-1414-76e3d0715c4a@android.com>

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.

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?

ACPI developers, do you think this should be backported?

thanks,

greg k-h

  reply	other threads:[~2018-05-10  6:55 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-09 21:30 ACPICA: acpi: acpica: fix acpi operand cache leak in nseval.c Mark Salyzyn
2018-05-10  6:55 ` Greg KH [this message]
2018-05-10 18:45   ` Schmauss, Erik
2018-05-11  5:23     ` Greg KH
2018-05-15 17:36       ` Schmauss, Erik
2018-05-15 20:42         ` Mark Salyzyn

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180510065519.GC25873@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=erik.schmauss@intel.com \
    --cc=kernel-team@android.com \
    --cc=kkamagui@gmail.com \
    --cc=rafael.j.wysocki@intel.com \
    --cc=salyzyn@android.com \
    --cc=stable@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.