rpms/bzip2
7
0
Fork 0
Code Issues Pull Requests Releases Activity

Fix regressions introduced by the previous patch

Browse Source 
Resolves: RHEL-71140
This commit is contained in:
Jakub Martisko 2024-12-19 12:23:29 +01:00
parent f9ed8e44ad
commit 92b7ab78e1
2 changed files with 64 additions and 11 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

7
bzip2.spec
View File

@ -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)

68
decompress-out-of-bounds.patch
View File

@ -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 )
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