bzip2: Fix CVE-2019-12900

More details about this CVE:
https://nvd.nist.gov/vuln/detail/CVE-2019-12900

Signed-off-by: Josef Schlehofer <pepe.schlehofer@gmail.com>

2 files changed, 66 insertions, 1 deletions

diff --git a/package/utils/bzip2/Makefile b/package/utils/bzip2/Makefile
index ea2fc76833..0bf168c229 100644
--- a/package/utils/bzip2/Makefile
+++ b/package/utils/bzip2/Makefile
@@ -9,7 +9,7 @@ include $(TOPDIR)/rules.mk
 
 PKG_NAME:=bzip2
 PKG_VERSION:=1.0.6
-PKG_RELEASE:=4
+PKG_RELEASE:=5
 
 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz
 PKG_SOURCE_URL:=http://www.bzip.org/$(PKG_VERSION)
diff --git a/package/utils/bzip2/patches/020-CVE-2019-12900.patch b/package/utils/bzip2/patches/020-CVE-2019-12900.patch
new file mode 100644
index 0000000000..3f08c789ea
--- /dev/null
+++ b/package/utils/bzip2/patches/020-CVE-2019-12900.patch
@@ -0,0 +1,65 @@
+From 812a898b7622de90e98f103ff7fed0984e4548e4 Mon Sep 17 00:00:00 2001
+From: Mark Wielaard <mark@klomp.org>
+Date: Wed, 3 Jul 2019 01:28:11 +0200
+Subject: [PATCH] Accept as many selectors as the file format allows.
+
+But ignore any larger than the theoretical maximum, BZ_MAX_SELECTORS.
+
+The theoretical maximum number of selectors depends on the maximum
+blocksize (900000 bytes) and the number of symbols (50) that can be
+encoded with a different Huffman tree. BZ_MAX_SELECTORS is 18002.
+
+But the bzip2 file format allows the number of selectors to be encoded
+with 15 bits (because 18002 isn't a factor of 2 and doesn't fit in
+14 bits). So the file format maximum is 32767 selectors.
+
+Some bzip2 encoders might actually have written out more selectors
+than the theoretical maximum because they rounded up the number of
+selectors to some convenient factor of 8.
+
+The extra 14766 selectors can never be validly used by the decompression
+algorithm. So we can read them, but then discard them.
+
+This is effectively what was done (by accident) before we added a
+check for nSelectors to be at most BZ_MAX_SELECTORS to mitigate
+CVE-2019-12900.
+
+The extra selectors were written out after the array inside the
+EState struct. But the struct has extra space allocated after the
+selector arrays of 18060 bytes (which is larger than 14766).
+All of which will be initialized later (so the overwrite of that
+space with extra selector values would have been harmless).
+---
+ compress.c   |  2 +-
+ decompress.c | 10 +++++++-
+ 2 files changed, 8 insertions(+), 2 deletions(-)
+
+--- a/compress.c
++++ b/compress.c
+@@ -454,7 +454,7 @@ void sendMTFValues ( EState* s )
+
+    AssertH( nGroups < 8, 3002 );
+    AssertH( nSelectors < 32768 &&
+-            nSelectors <= (2 + (900000 / BZ_G_SIZE)),
++            nSelectors <= BZ_MAX_SELECTORS,
+             3003 );
+
+
+--- a/decompress.c
++++ b/decompress.c
+@@ -296,8 +296,14 @@ Int32 BZ2_decompress ( DState* s )
+             j++;
+             if (j >= nGroups) RETURN(BZ_DATA_ERROR);
+          }
+-         s->selectorMtf[i] = j;
++         /* Having more than BZ_MAX_SELECTORS doesn't make much sense
++            since they will never be used, but some implementations might
++            "round up" the number of selectors, so just ignore those. */
++         if (i < BZ_MAX_SELECTORS)
++           s->selectorMtf[i] = j;
+       }
++      if (nSelectors > BZ_MAX_SELECTORS)
++        nSelectors = BZ_MAX_SELECTORS;
+
+       /*--- Undo the MTF values for the selectors. ---*/
+       {