Re: [4.19.y PATCH 1/3] efi/x86/Add missing error handling to old_memmap 1:1 mapping code

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sat, Jun 29, 2019 at 10:47:00AM +0200, Ard Biesheuvel wrote:
> On Sat, 29 Jun 2019 at 08:57, Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> wrote:
> >
> > On Fri, Jun 28, 2019 at 11:42:13AM -0700, Srivatsa S. Bhat wrote:
> > > From: Gen Zhang <blackgod016574@xxxxxxxxx>
> > >
> > > commit 4e78921ba4dd0aca1cc89168f45039add4183f8e upstream.
> > >
> > > The old_memmap flow in efi_call_phys_prolog() performs numerous memory
> > > allocations, and either does not check for failure at all, or it does
> > > but fails to propagate it back to the caller, which may end up calling
> > > into the firmware with an incomplete 1:1 mapping.
> > >
> > > So let's fix this by returning NULL from efi_call_phys_prolog() on
> > > memory allocation failures only, and by handling this condition in the
> > > caller. Also, clean up any half baked sets of page tables that we may
> > > have created before returning with a NULL return value.
> > >
> > > Note that any failure at this level will trigger a panic() two levels
> > > up, so none of this makes a huge difference, but it is a nice cleanup
> > > nonetheless.
> >
> > With a description like this, why is this needed in a stable kernel if
> > it does not really fix anything useful?
> >
> 
> Because it fixes a 'CVE', remember? :-)

Thanks for your concerns. I have received other people disputing the 
CVEs these days. And if you are interested, you could kindly search 
all the CVEs I requested, almost all of them are marked
*DISPUTED* or under update to that, haha...

Anyway, I am just a starter in requesting CVE. It's my instructor told
me to request CVE for the patches... It is disputed by everybody now.

I am getting to know that a bug hard to exploit can not request CVE.
We should be really careful in doing so. Right?

Thanks
Gen



[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux