]> git.ipfire.org Git - thirdparty/grub.git/commitdiff
fs/fshelp: Catch impermissibly large block sizes in read helper
authorDaniel Axtens <dja@axtens.net>
Mon, 18 Jan 2021 00:46:39 +0000 (11:46 +1100)
committerDaniel Kiper <daniel.kiper@oracle.com>
Tue, 2 Mar 2021 14:54:18 +0000 (15:54 +0100)
A fuzzed HFS+ filesystem had log2blocksize = 22. This gave
log2blocksize + GRUB_DISK_SECTOR_BITS = 31. 1 << 31 = 0x80000000,
which is -1 as an int. This caused some wacky behavior later on in
the function, leading to out-of-bounds writes on the destination buffer.

Catch log2blocksize + GRUB_DISK_SECTOR_BITS >= 31. We could be stricter,
but this is the minimum that will prevent integer size weirdness.

Signed-off-by: Daniel Axtens <dja@axtens.net>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
grub-core/fs/fshelp.c

index 4c902adf3819ca5a655df2289734784b26fde0de..a2d0d297a52006bcc29620a125d721b98c68d0c5 100644 (file)
@@ -362,6 +362,18 @@ grub_fshelp_read_file (grub_disk_t disk, grub_fshelp_node_t node,
   grub_disk_addr_t i, blockcnt;
   int blocksize = 1 << (log2blocksize + GRUB_DISK_SECTOR_BITS);
 
+  /*
+   * Catch blatantly invalid log2blocksize. We could be a lot stricter, but
+   * this is the most permissive we can be before we start to see integer
+   * overflow/underflow issues.
+   */
+  if (log2blocksize + GRUB_DISK_SECTOR_BITS >= 31)
+    {
+      grub_error (GRUB_ERR_OUT_OF_RANGE,
+                 N_("blocksize too large"));
+      return -1;
+    }
+
   if (pos > filesize)
     {
       grub_error (GRUB_ERR_OUT_OF_RANGE,