Linux-EFI Archive on lore.kernel.org
 help / color / Atom feed
* [4.19.y PATCH 0/3] Backported fixes for 4.19 stable tree
@ 2019-06-28 18:41 Srivatsa S. Bhat
  2019-06-28 18:42 ` [4.19.y PATCH 1/3] efi/x86/Add missing error handling to old_memmap 1:1 mapping code Srivatsa S. Bhat
  2019-06-28 20:44 ` [4.19.y PATCH 0/3] Backported fixes for 4.19 stable tree Sasha Levin
  0 siblings, 2 replies; 9+ messages in thread
From: Srivatsa S. Bhat @ 2019-06-28 18:41 UTC (permalink / raw)
  To: stable, gregkh
  Cc: linux-efi, Rob Bradford, David S. Miller, Linus Torvalds,
	Gen Zhang, Thomas Gleixner, Ingo Molnar, Peter Zijlstra,
	Ard Biesheuvel, akaher, srinidhir, bvikas, amakhalov, srivatsab,
	srivatsa

Hi Greg,

This patchset includes a few backported fixes for the 4.19 stable tree.
I would appreciate if you could kindly consider including them in the
next release.

Thank you!

Regards,
Srivatsa

---

Gen Zhang (3):
      efi/x86/Add missing error handling to old_memmap 1:1 mapping code
      ip_sockglue: Fix missing-check bug in ip_ra_control()
      ipv6_sockglue: Fix a missing-check bug in ip6_ra_control()


 arch/x86/platform/efi/efi.c    |    2 ++
 arch/x86/platform/efi/efi_64.c |    9 ++++++---
 net/ipv4/ip_sockglue.c         |    2 ++
 net/ipv6/ipv6_sockglue.c       |    2 ++
 4 files changed, 12 insertions(+), 3 deletions(-)

^ permalink raw reply	[flat|nested] 9+ messages in thread

* [4.19.y PATCH 1/3] efi/x86/Add missing error handling to old_memmap 1:1 mapping code
  2019-06-28 18:41 [4.19.y PATCH 0/3] Backported fixes for 4.19 stable tree Srivatsa S. Bhat
@ 2019-06-28 18:42 ` Srivatsa S. Bhat
  2019-06-29  6:57   ` Greg KH
  2019-06-28 20:44 ` [4.19.y PATCH 0/3] Backported fixes for 4.19 stable tree Sasha Levin
  1 sibling, 1 reply; 9+ messages in thread
From: Srivatsa S. Bhat @ 2019-06-28 18:42 UTC (permalink / raw)
  To: stable, gregkh
  Cc: Gen Zhang, Ard Biesheuvel, Linus Torvalds, Peter Zijlstra,
	Rob Bradford, Thomas Gleixner, linux-efi, Ingo Molnar, akaher,
	srinidhir, bvikas, amakhalov, srivatsab, srivatsa

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.

[ardb: update commit log, add efi_call_phys_epilog() call on error path]

Signed-off-by: Gen Zhang <blackgod016574@gmail.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Rob Bradford <robert.bradford@intel.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-efi@vger.kernel.org
Link: http://lkml.kernel.org/r/20190525112559.7917-2-ard.biesheuvel@linaro.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Srivatsa S. Bhat (VMware) <srivatsa@csail.mit.edu>
---

 arch/x86/platform/efi/efi.c    |    2 ++
 arch/x86/platform/efi/efi_64.c |    9 ++++++---
 2 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
index 9061bab..353019d 100644
--- a/arch/x86/platform/efi/efi.c
+++ b/arch/x86/platform/efi/efi.c
@@ -86,6 +86,8 @@ static efi_status_t __init phys_efi_set_virtual_address_map(
 	pgd_t *save_pgd;
 
 	save_pgd = efi_call_phys_prolog();
+	if (!save_pgd)
+		return EFI_ABORTED;
 
 	/* Disable interrupts around EFI calls: */
 	local_irq_save(flags);
diff --git a/arch/x86/platform/efi/efi_64.c b/arch/x86/platform/efi/efi_64.c
index ee5d08f..dfc809b 100644
--- a/arch/x86/platform/efi/efi_64.c
+++ b/arch/x86/platform/efi/efi_64.c
@@ -84,13 +84,15 @@ pgd_t * __init efi_call_phys_prolog(void)
 
 	if (!efi_enabled(EFI_OLD_MEMMAP)) {
 		efi_switch_mm(&efi_mm);
-		return NULL;
+		return efi_mm.pgd;
 	}
 
 	early_code_mapping_set_exec(1);
 
 	n_pgds = DIV_ROUND_UP((max_pfn << PAGE_SHIFT), PGDIR_SIZE);
 	save_pgd = kmalloc_array(n_pgds, sizeof(*save_pgd), GFP_KERNEL);
+	if (!save_pgd)
+		return NULL;
 
 	/*
 	 * Build 1:1 identity mapping for efi=old_map usage. Note that
@@ -138,10 +140,11 @@ pgd_t * __init efi_call_phys_prolog(void)
 		pgd_offset_k(pgd * PGDIR_SIZE)->pgd &= ~_PAGE_NX;
 	}
 
-out:
 	__flush_tlb_all();
-
 	return save_pgd;
+out:
+	efi_call_phys_epilog(save_pgd);
+	return NULL;
 }
 
 void __init efi_call_phys_epilog(pgd_t *save_pgd)


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [4.19.y PATCH 0/3] Backported fixes for 4.19 stable tree
  2019-06-28 18:41 [4.19.y PATCH 0/3] Backported fixes for 4.19 stable tree Srivatsa S. Bhat
  2019-06-28 18:42 ` [4.19.y PATCH 1/3] efi/x86/Add missing error handling to old_memmap 1:1 mapping code Srivatsa S. Bhat
@ 2019-06-28 20:44 ` Sasha Levin
  1 sibling, 0 replies; 9+ messages in thread
From: Sasha Levin @ 2019-06-28 20:44 UTC (permalink / raw)
  To: Srivatsa S. Bhat
  Cc: stable, gregkh, linux-efi, Rob Bradford, David S. Miller,
	Linus Torvalds, Gen Zhang, Thomas Gleixner, Ingo Molnar,
	Peter Zijlstra, Ard Biesheuvel, akaher, srinidhir, bvikas,
	amakhalov, srivatsab, netdev

On Fri, Jun 28, 2019 at 11:41:54AM -0700, Srivatsa S. Bhat wrote:
>Hi Greg,
>
>This patchset includes a few backported fixes for the 4.19 stable tree.
>I would appreciate if you could kindly consider including them in the
>next release.

+ netdev@

David Miller deals with the 4.19 net/ patches, so this will need to go
through (or acked by) him.

--
Thanks,
Sasha

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [4.19.y PATCH 1/3] efi/x86/Add missing error handling to old_memmap 1:1 mapping code
  2019-06-28 18:42 ` [4.19.y PATCH 1/3] efi/x86/Add missing error handling to old_memmap 1:1 mapping code Srivatsa S. Bhat
@ 2019-06-29  6:57   ` Greg KH
  2019-06-29  8:47     ` Ard Biesheuvel
  0 siblings, 1 reply; 9+ messages in thread
From: Greg KH @ 2019-06-29  6:57 UTC (permalink / raw)
  To: Srivatsa S. Bhat
  Cc: stable, Gen Zhang, Ard Biesheuvel, Linus Torvalds,
	Peter Zijlstra, Rob Bradford, Thomas Gleixner, linux-efi,
	Ingo Molnar, akaher, srinidhir, bvikas, amakhalov, srivatsab

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?

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [4.19.y PATCH 1/3] efi/x86/Add missing error handling to old_memmap 1:1 mapping code
  2019-06-29  6:57   ` Greg KH
@ 2019-06-29  8:47     ` Ard Biesheuvel
  2019-06-29  8:57       ` Gen Zhang
  2019-06-29  9:10       ` Greg KH
  0 siblings, 2 replies; 9+ messages in thread
From: Ard Biesheuvel @ 2019-06-29  8:47 UTC (permalink / raw)
  To: Greg KH
  Cc: Srivatsa S. Bhat, stable, Gen Zhang, Linus Torvalds,
	Peter Zijlstra, Rob Bradford, Thomas Gleixner, linux-efi,
	Ingo Molnar, akaher, srinidhir, bvikas, amakhalov, srivatsab

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? :-)

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [4.19.y PATCH 1/3] efi/x86/Add missing error handling to old_memmap 1:1 mapping code
  2019-06-29  8:47     ` Ard Biesheuvel
@ 2019-06-29  8:57       ` Gen Zhang
  2019-06-29  9:10       ` Greg KH
  1 sibling, 0 replies; 9+ messages in thread
From: Gen Zhang @ 2019-06-29  8:57 UTC (permalink / raw)
  To: Ard Biesheuvel
  Cc: Greg KH, Srivatsa S. Bhat, stable, Linus Torvalds,
	Peter Zijlstra, Rob Bradford, Thomas Gleixner, linux-efi,
	Ingo Molnar, akaher, srinidhir, bvikas, amakhalov, srivatsab

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? :-)

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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [4.19.y PATCH 1/3] efi/x86/Add missing error handling to old_memmap 1:1 mapping code
  2019-06-29  8:47     ` Ard Biesheuvel
  2019-06-29  8:57       ` Gen Zhang
@ 2019-06-29  9:10       ` Greg KH
  2019-06-29 21:11         ` Ard Biesheuvel
  1 sibling, 1 reply; 9+ messages in thread
From: Greg KH @ 2019-06-29  9:10 UTC (permalink / raw)
  To: Ard Biesheuvel
  Cc: Srivatsa S. Bhat, stable, Gen Zhang, Linus Torvalds,
	Peter Zijlstra, Rob Bradford, Thomas Gleixner, linux-efi,
	Ingo Molnar, akaher, srinidhir, bvikas, amakhalov, srivatsab

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.

greg k-h

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [4.19.y PATCH 1/3] efi/x86/Add missing error handling to old_memmap 1:1 mapping code
  2019-06-29  9:10       ` Greg KH
@ 2019-06-29 21:11         ` Ard Biesheuvel
  2019-06-29 21:49           ` Srivatsa S. Bhat
  0 siblings, 1 reply; 9+ messages in thread
From: Ard Biesheuvel @ 2019-06-29 21:11 UTC (permalink / raw)
  To: Greg KH
  Cc: Srivatsa S. Bhat, stable, Gen Zhang, Linus Torvalds,
	Peter Zijlstra, Rob Bradford, Thomas Gleixner, linux-efi,
	Ingo Molnar, akaher, srinidhir, bvikas, amakhalov, srivatsab

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.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [4.19.y PATCH 1/3] efi/x86/Add missing error handling to old_memmap 1:1 mapping code
  2019-06-29 21:11         ` Ard Biesheuvel
@ 2019-06-29 21:49           ` Srivatsa S. Bhat
  0 siblings, 0 replies; 9+ messages in thread
From: Srivatsa S. Bhat @ 2019-06-29 21:49 UTC (permalink / raw)
  To: Ard Biesheuvel, Greg KH
  Cc: stable, Gen Zhang, Linus Torvalds, Peter Zijlstra, Rob Bradford,
	Thomas Gleixner, linux-efi, Ingo Molnar, akaher, srinidhir,
	bvikas, amakhalov, srivatsab

On 6/29/19 2:11 PM, Ard Biesheuvel wrote:
> 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.
> 

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

^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, back to index

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-06-28 18:41 [4.19.y PATCH 0/3] Backported fixes for 4.19 stable tree Srivatsa S. Bhat
2019-06-28 18:42 ` [4.19.y PATCH 1/3] efi/x86/Add missing error handling to old_memmap 1:1 mapping code Srivatsa S. Bhat
2019-06-29  6:57   ` Greg KH
2019-06-29  8:47     ` Ard Biesheuvel
2019-06-29  8:57       ` Gen Zhang
2019-06-29  9:10       ` Greg KH
2019-06-29 21:11         ` Ard Biesheuvel
2019-06-29 21:49           ` Srivatsa S. Bhat
2019-06-28 20:44 ` [4.19.y PATCH 0/3] Backported fixes for 4.19 stable tree Sasha Levin

Linux-EFI Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-efi/0 linux-efi/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-efi linux-efi/ https://lore.kernel.org/linux-efi \
		linux-efi@vger.kernel.org linux-efi@archiver.kernel.org
	public-inbox-index linux-efi


Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-efi


AGPL code for this site: git clone https://public-inbox.org/ public-inbox