All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <gregkh@linuxfoundation.org>
To: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Zubin Mithra <zsm@chromium.org>, stable <stable@vger.kernel.org>,
	Guenter Roeck <groeck@chromium.org>,
	Gen Zhang <blackgod016574@gmail.com>,
	Darren Hart <dvhart@infradead.org>,
	Andy Shevchenko <andy@infradead.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>
Subject: Re: 4e78921ba4dd ("efi/x86/Add missing error handling to old_memmap 1:1 mapping code")
Date: Tue, 4 Jun 2019 15:45:59 +0200	[thread overview]
Message-ID: <20190604134559.GA8083@kroah.com> (raw)
In-Reply-To: <CAKv+Gu8a77xObE8UPhDZeqzXdm48vxHOqC4resfvRJLFPavgLQ@mail.gmail.com>

On Tue, Jun 04, 2019 at 03:39:15PM +0200, Ard Biesheuvel wrote:
> On Tue, 4 Jun 2019 at 14:34, Greg KH <gregkh@linuxfoundation.org> wrote:
> >
> > On Mon, Jun 03, 2019 at 03:38:52PM -0700, Zubin Mithra wrote:
> > > Hello,
> > >
> > > CVE-2019-12380 was fixed in the upstream linux kernel with the commit :-
> > > * 4e78921ba4dd ("efi/x86/Add missing error handling to old_memmap 1:1 mapping code")
> > >
> > > Could the patch be applied in order to v4.19.y?
> >
> > Now queued up, thanks.
> >
> 
> Given the discussion leading up to this, I'm slightly surprised.
> 
> As I alluded to in my questions to Zubin, I am concerned that the
> testing carried out on this patch has too little coverage, given that
> a) Chrome OS apparently does not boot in EFI mode
> b) therefore, Chrome OS there does not use efi=old_map
> c) Chrome OS hardware does not implement 5 level paging
> 
> I have done all the testing I could before merging the patch, but I
> would prefer to defer from backporting it until it hits a release. I
> know some people argue that this still does not provide sufficient
> coverage, but those are usually not the same people getting emails
> when their EFI systems no longer boot without any output whatsoever
> after upgrading from one stable kernel version to the next.

Ok, I'll go drop it.  Can you please email stable@vger when it is in a
release so that I know to queue it up then?

thanks,

greg k-h

  reply	other threads:[~2019-06-04 13:46 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-03 22:38 4e78921ba4dd ("efi/x86/Add missing error handling to old_memmap 1:1 mapping code") Zubin Mithra
2019-06-04  7:38 ` Ard Biesheuvel
2019-06-04  7:46   ` Greg Kroah-Hartman
2019-06-04  8:52     ` Guenter Roeck
2019-06-04  9:03       ` Ard Biesheuvel
2019-06-04  9:09       ` Greg Kroah-Hartman
2019-06-04 12:34 ` Greg KH
2019-06-04 13:39   ` Ard Biesheuvel
2019-06-04 13:45     ` Greg KH [this message]
2019-06-04 13:47       ` Ard Biesheuvel
2019-06-04 16:38     ` Zubin Mithra

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=20190604134559.GA8083@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=andy@infradead.org \
    --cc=ard.biesheuvel@linaro.org \
    --cc=blackgod016574@gmail.com \
    --cc=bp@alien8.de \
    --cc=dvhart@infradead.org \
    --cc=groeck@chromium.org \
    --cc=mingo@redhat.com \
    --cc=stable@vger.kernel.org \
    --cc=tglx@linutronix.de \
    --cc=zsm@chromium.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.