e8d57f
From 399719595f413158b3510128eb85f944654f960c Mon Sep 17 00:00:00 2001
e8d57f
From: DRC <information@libjpeg-turbo.org>
e8d57f
Date: Tue, 12 Jun 2018 20:27:00 -0500
e8d57f
Subject: [PATCH] tjLoadImage(): Fix FPE triggered by malformed BMP
e8d57f
e8d57f
In rdbmp.c, it is necessary to guard against 32-bit overflow/wraparound
e8d57f
when allocating the row buffer, because since BMP files have 32-bit
e8d57f
width and height fields, the value of biWidth can be up to 4294967295.
e8d57f
Specifically, if biWidth is 1073741824 and cinfo->input_components = 4,
e8d57f
then the samplesperrow argument in alloc_sarray() would wrap around to
e8d57f
0, and a division by zero error would occur at line 458 in jmemmgr.c.
e8d57f
e8d57f
If biWidth is set to a higher value, then samplesperrow would wrap
e8d57f
around to a small number, which would likely cause a buffer overflow
e8d57f
(this has not been tested or verified.)
e8d57f
---
e8d57f
 rdbmp.c | 6 ++++++
e8d57f
 1 file changed, 6 insertions(+)
e8d57f
e8d57f
diff --git a/rdbmp.c b/rdbmp.c
e8d57f
index eaa7086..4104b68 100644
e8d57f
--- a/rdbmp.c
e8d57f
+++ b/rdbmp.c
e8d57f
@@ -434,6 +434,12 @@ start_input_bmp (j_compress_ptr cinfo, cjpeg_source_ptr sinfo)
e8d57f
     progress->total_extra_passes++; /* count file input as separate pass */
e8d57f
   }
e8d57f
 
e8d57f
+  /* Ensure that biWidth * cinfo->input_components doesn't exceed the maximum
e8d57f
+     value of the JDIMENSION type.  This is only a danger with BMP files, since
e8d57f
+     their width and height fields are 32-bit integers. */
e8d57f
+  if ((unsigned long long)biWidth *
e8d57f
+      (unsigned long long)cinfo->input_components > 0xFFFFFFFFULL)
e8d57f
+    ERREXIT(cinfo, JERR_WIDTH_OVERFLOW);
e8d57f
   /* Allocate one-row buffer for returned data */
e8d57f
   source->pub.buffer = (*cinfo->mem->alloc_sarray)
e8d57f
     ((j_common_ptr) cinfo, JPOOL_IMAGE,
e8d57f
-- 
e8d57f
2.17.1
e8d57f