All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ard Biesheuvel <ard.biesheuvel@linaro.org>
To: Zubin Mithra <zsm@chromium.org>
Cc: stable <stable@vger.kernel.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	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 09:38:27 +0200	[thread overview]
Message-ID: <CAKv+Gu8VioGy1h8n0zKAqj+m_PBZdRU+BmJDH7=D7=iEiKRpgw@mail.gmail.com> (raw)
In-Reply-To: <20190603223851.GA162395@google.com>

On Tue, 4 Jun 2019 at 00:38, Zubin Mithra <zsm@chromium.org> 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?
>
> Tests run:
> * Chrome OS tryjob
>

Unless I am missing something, it seems to me that there is some
inflation going on when it comes to CVE number assignments.

The code in question only affects systems that are explicitly booted
with efi=old_map, and the memory allocation occurs so early during the
boot sequence that even if we fail and handle it gracefully, it is
highly unlikely that we can get to a point where the system is usable
at all.

Does Chrome OS boot in EFI mode? Does it use efi=old_map? Is the
kernel built with 5 level paging enabled? Did you run it on 5 level
paging hardware?

Or is this just a tick the box exercise?

Also, I am annoyed (does it show? :-))  that nobody mentioned the CVE
at any point when the patch was under review (not even privately)

  reply	other threads:[~2019-06-04  7:38 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 [this message]
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
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='CAKv+Gu8VioGy1h8n0zKAqj+m_PBZdRU+BmJDH7=D7=iEiKRpgw@mail.gmail.com' \
    --to=ard.biesheuvel@linaro.org \
    --cc=andy@infradead.org \
    --cc=blackgod016574@gmail.com \
    --cc=bp@alien8.de \
    --cc=dvhart@infradead.org \
    --cc=gregkh@linuxfoundation.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.