All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Kiper <daniel.kiper@oracle.com>
To: grub-devel@gnu.org
Cc: 93sam@debian.org, alexander.burmashev@oracle.com,
	amakhalov@vmware.com, chris.coulson@canonical.com,
	cjwatson@debian.org, cperry@redhat.com, darren.kenny@oracle.com,
	darren.moffat@oracle.com, dave.miner@oracle.com,
	degranit@microsoft.com, eric.snowberg@oracle.com,
	ilya.okomin@oracle.com, jan.setjeeilers@oracle.com,
	jerecox@microsoft.com, jesse@eclypsium.com,
	john.haxby@oracle.com, kanth.ghatraju@oracle.com,
	konrad.wilk@oracle.com, mbenatto@redhat.com,
	mickey@eclypsium.com, msrc57813grub@microsoft.com,
	phcoder@gmail.com, pjones@redhat.com, sajacobu@microsoft.com,
	todd.vierling@oracle.com, xnox@ubuntu.com
Subject: [SECURITY PATCH 22/28] lvm: Fix two more potential data-dependent alloc overflows
Date: Wed, 29 Jul 2020 19:00:35 +0200	[thread overview]
Message-ID: <20200729170041.14082-23-daniel.kiper@oracle.com> (raw)
In-Reply-To: <20200729170041.14082-1-daniel.kiper@oracle.com>

From: Peter Jones <pjones@redhat.com>

It appears to be possible to make a (possibly invalid) lvm PV with
a metadata size field that overflows our type when adding it to the
address we've allocated. Even if it doesn't, it may be possible to do so
with the math using the outcome of that as an operand. Check them both.

Signed-off-by: Peter Jones <pjones@redhat.com>
Signed-off-by: Darren Kenny <darren.kenny@oracle.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
---
 grub-core/disk/lvm.c | 48 ++++++++++++++++++++++++++++++++++++++++--------
 1 file changed, 40 insertions(+), 8 deletions(-)

diff --git a/grub-core/disk/lvm.c b/grub-core/disk/lvm.c
index 48e36b4f3..753545146 100644
--- a/grub-core/disk/lvm.c
+++ b/grub-core/disk/lvm.c
@@ -25,6 +25,7 @@
 #include <grub/lvm.h>
 #include <grub/partition.h>
 #include <grub/i18n.h>
+#include <grub/safemath.h>
 
 #ifdef GRUB_UTIL
 #include <grub/emu/misc.h>
@@ -138,10 +139,11 @@ grub_lvm_detect (grub_disk_t disk,
 {
   grub_err_t err;
   grub_uint64_t mda_offset, mda_size;
+  grub_size_t ptr;
   char buf[GRUB_LVM_LABEL_SIZE];
   char vg_id[GRUB_LVM_ID_STRLEN+1];
   char pv_id[GRUB_LVM_ID_STRLEN+1];
-  char *metadatabuf, *vgname;
+  char *metadatabuf, *mda_end, *vgname;
   const char *p, *q;
   struct grub_lvm_label_header *lh = (struct grub_lvm_label_header *) buf;
   struct grub_lvm_pv_header *pvh;
@@ -242,19 +244,31 @@ grub_lvm_detect (grub_disk_t disk,
 		   grub_le_to_cpu64 (rlocn->size) -
 		   grub_le_to_cpu64 (mdah->size));
     }
-  p = q = metadatabuf + grub_le_to_cpu64 (rlocn->offset);
 
-  while (*q != ' ' && q < metadatabuf + mda_size)
-    q++;
-
-  if (q == metadatabuf + mda_size)
+  if (grub_add ((grub_size_t)metadatabuf,
+		(grub_size_t)grub_le_to_cpu64 (rlocn->offset),
+		&ptr))
     {
+ error_parsing_metadata:
 #ifdef GRUB_UTIL
       grub_util_info ("error parsing metadata");
 #endif
       goto fail2;
     }
 
+  p = q = (char *)ptr;
+
+  if (grub_add ((grub_size_t)metadatabuf, (grub_size_t)mda_size, &ptr))
+    goto error_parsing_metadata;
+
+  mda_end = (char *)ptr;
+
+  while (*q != ' ' && q < mda_end)
+    q++;
+
+  if (q == mda_end)
+    goto error_parsing_metadata;
+
   vgname_len = q - p;
   vgname = grub_malloc (vgname_len + 1);
   if (!vgname)
@@ -406,8 +420,26 @@ grub_lvm_detect (grub_disk_t disk,
 	      {
 		const char *iptr;
 		char *optr;
-		lv->fullname = grub_malloc (sizeof ("lvm/") - 1 + 2 * vgname_len
-					    + 1 + 2 * s + 1);
+
+		/*
+		 * This is kind of hard to read with our safe (but rather
+		 * baroque) math primatives, but it boils down to:
+		 *
+		 *   sz0 = vgname_len * 2 + 1 +
+		 *         s * 2 + 1 +
+		 *         sizeof ("lvm/") - 1;
+		 */
+		grub_size_t sz0 = vgname_len, sz1 = s;
+
+		if (grub_mul (sz0, 2, &sz0) ||
+		    grub_add (sz0, 1, &sz0) ||
+		    grub_mul (sz1, 2, &sz1) ||
+		    grub_add (sz1, 1, &sz1) ||
+		    grub_add (sz0, sz1, &sz0) ||
+		    grub_add (sz0, sizeof ("lvm/") - 1, &sz0))
+		  goto lvs_fail;
+
+		lv->fullname = grub_malloc (sz0);
 		if (!lv->fullname)
 		  goto lvs_fail;
 
-- 
2.11.0



  parent reply	other threads:[~2020-07-29 17:03 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-29 17:00 [SECURITY PATCH 00/28] Multiple GRUB2 vulnerabilities - BootHole Daniel Kiper
2020-07-29 17:00 ` [SECURITY PATCH 01/28] yylex: Make lexer fatal errors actually be fatal Daniel Kiper
2020-07-29 17:00 ` [SECURITY PATCH 02/28] safemath: Add some arithmetic primitives that check for overflow Daniel Kiper
2020-07-29 17:00 ` [SECURITY PATCH 03/28] calloc: Make sure we always have an overflow-checking calloc() available Daniel Kiper
2020-07-29 17:00 ` [SECURITY PATCH 04/28] calloc: Use calloc() at most places Daniel Kiper
2020-07-29 17:00 ` [SECURITY PATCH 05/28] malloc: Use overflow checking primitives where we do complex allocations Daniel Kiper
2021-09-10 16:10   ` Glenn Washburn
2020-07-29 17:00 ` [SECURITY PATCH 06/28] iso9660: Don't leak memory on realloc() failures Daniel Kiper
2020-07-29 17:00 ` [SECURITY PATCH 07/28] font: Do not load more than one NAME section Daniel Kiper
2020-07-29 17:00 ` [SECURITY PATCH 08/28] gfxmenu: Fix double free in load_image() Daniel Kiper
2020-07-29 17:00 ` [SECURITY PATCH 09/28] xnu: Fix double free in grub_xnu_devprop_add_property() Daniel Kiper
2020-07-29 17:00 ` [SECURITY PATCH 10/28] json: Avoid a double-free when parsing fails Daniel Kiper
2020-07-29 17:00 ` [SECURITY PATCH 11/28] lzma: Make sure we don't dereference past array Daniel Kiper
2020-07-29 17:00 ` [SECURITY PATCH 12/28] term: Fix overflow on user inputs Daniel Kiper
2020-07-29 17:00 ` [SECURITY PATCH 13/28] udf: Fix memory leak Daniel Kiper
2020-07-29 17:00 ` [SECURITY PATCH 14/28] multiboot2: Fix memory leak if grub_create_loader_cmdline() fails Daniel Kiper
2020-07-29 17:00 ` [SECURITY PATCH 15/28] tftp: Do not use priority queue Daniel Kiper
2020-07-29 17:00 ` [SECURITY PATCH 16/28] relocator: Protect grub_relocator_alloc_chunk_addr() input args against integer underflow/overflow Daniel Kiper
2020-07-29 17:00 ` [SECURITY PATCH 17/28] relocator: Protect grub_relocator_alloc_chunk_align() max_addr against integer underflow Daniel Kiper
2020-07-29 17:00 ` [SECURITY PATCH 18/28] script: Remove unused fields from grub_script_function struct Daniel Kiper
2020-07-29 17:00 ` [SECURITY PATCH 19/28] script: Avoid a use-after-free when redefining a function during execution Daniel Kiper
2020-07-29 17:00 ` [SECURITY PATCH 20/28] relocator: Fix grub_relocator_alloc_chunk_align() top memory allocation Daniel Kiper
2020-07-29 17:00 ` [SECURITY PATCH 21/28] hfsplus: Fix two more overflows Daniel Kiper
2020-07-29 17:00 ` Daniel Kiper [this message]
2020-07-29 17:00 ` [SECURITY PATCH 23/28] emu: Make grub_free(NULL) safe Daniel Kiper
2020-07-29 17:00 ` [SECURITY PATCH 24/28] efi: Fix some malformed device path arithmetic errors Daniel Kiper
2020-07-29 17:00 ` [SECURITY PATCH 25/28] efi/chainloader: Propagate errors from copy_file_path() Daniel Kiper
2020-07-29 17:00 ` [SECURITY PATCH 26/28] efi: Fix use-after-free in halt/reboot path Daniel Kiper
2020-07-29 17:00 ` [SECURITY PATCH 27/28] loader/linux: Avoid overflow on initrd size calculation Daniel Kiper
2020-07-29 17:00 ` [SECURITY PATCH 28/28] linux: Fix integer overflows in initrd size handling Daniel Kiper
2020-07-29 20:12 ` [SECURITY PATCH 00/28] Multiple GRUB2 vulnerabilities - BootHole Christian Hesse
2020-07-29 20:20   ` John Paul Adrian Glaubitz
2020-07-29 21:20     ` Dimitri John Ledkov
2020-07-29 21:33       ` John Paul Adrian Glaubitz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200729170041.14082-23-daniel.kiper@oracle.com \
    --to=daniel.kiper@oracle.com \
    --cc=93sam@debian.org \
    --cc=alexander.burmashev@oracle.com \
    --cc=amakhalov@vmware.com \
    --cc=chris.coulson@canonical.com \
    --cc=cjwatson@debian.org \
    --cc=cperry@redhat.com \
    --cc=darren.kenny@oracle.com \
    --cc=darren.moffat@oracle.com \
    --cc=dave.miner@oracle.com \
    --cc=degranit@microsoft.com \
    --cc=eric.snowberg@oracle.com \
    --cc=grub-devel@gnu.org \
    --cc=ilya.okomin@oracle.com \
    --cc=jan.setjeeilers@oracle.com \
    --cc=jerecox@microsoft.com \
    --cc=jesse@eclypsium.com \
    --cc=john.haxby@oracle.com \
    --cc=kanth.ghatraju@oracle.com \
    --cc=konrad.wilk@oracle.com \
    --cc=mbenatto@redhat.com \
    --cc=mickey@eclypsium.com \
    --cc=msrc57813grub@microsoft.com \
    --cc=phcoder@gmail.com \
    --cc=pjones@redhat.com \
    --cc=sajacobu@microsoft.com \
    --cc=todd.vierling@oracle.com \
    --cc=xnox@ubuntu.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.