Re: 4e78921ba4dd ("efi/x86/Add missing error handling to old_memmap 1:1 mapping code")

[Greg Kroah-Hartman <gregkh@linuxfoundation.org>]

On Tue, Jun 04, 2019 at 09:38:27AM +0200, Ard Biesheuvel wrote:
> 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)

CVEs are almost always asked for _after_ the patch is merged, as the
average fix-to-CVE request timeframe is -100 days.

Also, for the kernel, CVEs almost mean nothing, so if this really isn't
an issue, I'll not backport this.

And I really doubt that any chromeos device has 5 level page tables just
yet :)

thanks,

greg k-h