On 6/29/19 2:11 PM, Ard Biesheuvel wrote: > On Sat, 29 Jun 2019 at 11:11, Greg KH <[email protected]> wrote: >> >> On Sat, Jun 29, 2019 at 10:47:00AM +0200, Ard Biesheuvel wrote: >>> On Sat, 29 Jun 2019 at 08:57, Greg KH <[email protected]> wrote: >>>> >>>> On Fri, Jun 28, 2019 at 11:42:13AM -0700, Srivatsa S. Bhat wrote: >>>>> From: Gen Zhang <[email protected]> >>>>> >>>>> 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? :-) >> >> No, I don't remember that at all. >> >> Remember, I get 1000+ emails a day to do something with, and hence, have >> the short-term memory of prior emails of a squirrel. >> >> Also, CVEs mean nothing, anyone can get one and they are impossible to >> revoke, so don't treat them like they are "authoritative" at all. >> > > To refresh your memory: I already nacked this backport once before, on > the grounds that the CVE is completely bogus. >
Oh! I didn't know that this patch was discussed here before (this is the first time I'm posting these backports). Anyway, based on the discussion above, Greg, please ignore this patchset. Regards, Srivatsa
