diff --git a/bzip2.spec b/bzip2.spec index b1d1514..261043b 100644 --- a/bzip2.spec +++ b/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 - 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 - 1.0.6-27 - Fixes out of bounds access in BZ2_decompress (RHEL-64929) diff --git a/decompress-out-of-bounds.patch b/decompress-out-of-bounds.patch index eaf098d..0780957 100644 --- a/decompress-out-of-bounds.patch +++ b/decompress-out-of-bounds.patch @@ -1,13 +1,61 @@ +From b07b105d1b66e32760095e3602261738443b9e13 Mon Sep 17 00:00:00 2001 +From: Mark Wielaard +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 ) - GET_BITS(BZ_X_SELECTOR_1, nGroups, 3); - if (nGroups < 2 || nGroups > 6) RETURN(BZ_DATA_ERROR); - GET_BITS(BZ_X_SELECTOR_2, nSelectors, 15); -- if (nSelectors < 1) RETURN(BZ_DATA_ERROR); -+ if (nSelectors < 1 || nSelectors > BZ_MAX_SELECTORS) RETURN(BZ_DATA_ERROR); - for (i = 0; i < nSelectors; i++) { - j = 0; - while (True) { +@@ -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. ---*/ + { +-- +cgit