Some cherry-picks (Was: [PATCH] bzip2: Fix return value when combining --test,-t and -q.)

[Mark Wielaard]

On Mon, 2019-06-24 at 11:34 +0200, Mark Wielaard wrote:
> On Mon, 2019-06-24 at 10:31 +0200, Santiago Ruano Rincón wrote:
> > For information, Federico Mena (in CC) is taking over the development
> > of
> > bzip2: https://people.gnome.org/~federico/blog/maintaining-bzip2.html
> > 
> > You should consider coordinating your efforts!
> 
> Thanks. I assumed Federico was already on the bzip2-devel mailinglist.
> We did email earlier to discuss bzip2 maintenance and that all the
> infrastructure was already setup on the new sourceware.org bzip2
> project. But it seems we did some duplicate work. Sorry for the
> miscommunication.
> 
> It looks like we picked at least similar patches for the C sources, so
> those look mostly identical. I'll go over the remaining differences and
> try to cherry-pick or merge them into the bzip2 git repo.

I cherry-picked the following:

commit ff986850159a1ea0c75617ffa792d1bb2069856e
Author: Federico Mena Quintero <federico@gnome.org>
Date:   Wed May 29 17:14:27 2019 -0500

    Change a magic number (6) for a constant (BZ_N_GROUPS).
    
    decompress.c (BZ2_decompress): Check nGroups against BZ_N_GROUPS.

commit 7ed62bfb46e87a9e878712603469440e6882b184
Author: Albert Astals Cid <aacid@kde.org>
Date:   Tue May 28 19:35:18 2019 +0200

    Make sure nSelectors is not out of range
    
    nSelectors is used in a loop from 0 to nSelectors to access selectorMtf
    which is
        UChar    selectorMtf[BZ_MAX_SELECTORS];
    so if nSelectors is bigger than BZ_MAX_SELECTORS it'll do an invalid memory
    access
    
    Fixes out of bounds access discovered while fuzzying karchive
    
    This was reported as CVE-2019-12900
    BZ2_decompress in decompress.c in bzip2 through 1.0.6 has an
    out-of-bounds write when there are many selectors.

commit 16f2c753f9959e8d7c7e1fa771b8ccc5821427aa
Author: Paul Kehrer <paul.l.kehrer@gmail.com>
Date:   Sat Jun 8 10:06:40 2019 -0400

    Fix undefined behavior in the macros SET_BH, CLEAR_BH, & ISSET_BH
    
    These macros contain this pattern:
    1 << ((Int32_value) & 31
    
    This causes the undefined behavior sanitizers in clang and gcc to
    complain because the shift, while ultimately stored to an unsigned
    variable, is done as a signed value. Adding a cast to unsigned for
    the int32 value resolves this issue.

That makes the sources almost identical, modulo some whitespace issues
(inconsistent use of tab/space as indent). And some Windows specific
tweaks that I am not able to test (but they are probably correct though
).

The only remaining difference between the trees (for the C sources) is
the fix for O_CLOEXEC. I would like to better understand the
(different) Debian solution for that:

https://sources.debian.org/patches/bzip2/1.0.6-9/bzip2recover-race-open-output.diff/

Cheers,

Mark