On Sat, 29 Jun 2019 at 11:11, Greg KH gregkh@linuxfoundation.org wrote:
On Sat, Jun 29, 2019 at 10:47:00AM +0200, Ard Biesheuvel wrote:
On Sat, 29 Jun 2019 at 08:57, Greg KH gregkh@linuxfoundation.org wrote:
On Fri, Jun 28, 2019 at 11:42:13AM -0700, Srivatsa S. Bhat wrote:
From: Gen Zhang blackgod016574@gmail.com
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.