Fix regressions introduced by the previous patch

Resolves: RHEL-71140

bzip2.spec

@@ -3,7 +3,7 @@
 Summary: A file compression utility
 Name: bzip2
 Version: 1.0.6
-Release: 27%{?dist}
+Release: 28%{?dist}
 License: BSD
 Group: Applications/File
 URL: http://www.bzip.org/
@@ -142,6 +142,11 @@ ln -s bzgrep.1 $RPM_BUILD_ROOT%{_mandir}/man1/bzfgrep.1
 %{_libdir}/pkgconfig/bzip2.pc
 
 %changelog
+* Thu Dec 19 2024 Jakub Martisko <jamartis@redhat.com> - 1.0.6-28
+- The previous fix caused some regressions
+- Use an updated patch that deals with the original issue+the regressions
+Resolves: RHEL-71140
+
 * Tue Oct 29 2024 Jacek Migacz <jmigacz@redhat.com> - 1.0.6-27
 - Fixes out of bounds access in BZ2_decompress (RHEL-64929)
 

decompress-out-of-bounds.patch

@@ -1,13 +1,61 @@
+From b07b105d1b66e32760095e3602261738443b9e13 Mon Sep 17 00:00:00 2001
+From: Mark Wielaard <mark@klomp.org>
+Date: Wed, 3 Jul 2019 01:28:11 +0200
+Subject: 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).
+
+Note by jamartis: 
+The original patch Described above also reverts some changes that were made after 1.0.6.
+Since these changes are not yet present in 1.0.6, they don't need to be reverted and are thus
+removed from the original patch
+
+
+---
 diff --git a/decompress.c b/decompress.c
-index ab6a624db17a1c124b5be09c04b0e99d950b70ff..f3db91d14f6ed09f76fbd5c73f7db2cba5f577da 100644
+index 20ce493..3303499 100644
 --- a/decompress.c
 +++ b/decompress.c
-@@ -287,7 +287,7 @@ Int32 BZ2_decompress ( DState* s )
+@@ -296,8 +296,14 @@ Int32 BZ2_decompress ( DState* s )
-       GET_BITS(BZ_X_SELECTOR_1, nGroups, 3);
+             j++;
-       if (nGroups < 2 || nGroups > 6) RETURN(BZ_DATA_ERROR);
+             if (j >= nGroups) RETURN(BZ_DATA_ERROR);
-       GET_BITS(BZ_X_SELECTOR_2, nSelectors, 15);
+          }
--      if (nSelectors < 1) RETURN(BZ_DATA_ERROR);
+-         s->selectorMtf[i] = j;
-+      if (nSelectors < 1 || nSelectors > BZ_MAX_SELECTORS) RETURN(BZ_DATA_ERROR);
++         /* Having more than BZ_MAX_SELECTORS doesn't make much sense
-       for (i = 0; i < nSelectors; i++) {
++            since they will never be used, but some implementations might
-          j = 0;
++            "round up" the number of selectors, so just ignore those. */
-          while (True) {
++         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. ---*/
+       {
+-- 
+cgit