From: Mark Wielaard <mark@klomp.org>
To: "Santiago Ruano Rincón" <santiago@debian.org>
Cc: bzip2-devel@sourceware.org,
Anibal Monsalve Salazar <anibal@debian.org>,
Anthony Fok <foka@debian.org>,
Federico Mena Quintero <federico@gnome.org>
Subject: Some cherry-picks (Was: [PATCH] bzip2: Fix return value when combining --test,-t and -q.)
Date: Tue, 01 Jan 2019 00:00:00 -0000 [thread overview]
Message-ID: <909f618c164a1aee716dac9f6620aa90c5260ece.camel@klomp.org> (raw)
In-Reply-To: <c55e001242b3e6c33d429c2f5dab2fcd132bcb6b.camel@klomp.org>
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
next prev parent reply other threads:[~2019-06-24 13:55 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-01 0:00 [PATCH] bzip2: Fix return value when combining --test,-t and -q Mark Wielaard
2019-01-01 0:00 ` Santiago Ruano Rincón
2019-01-01 0:00 ` Mark Wielaard
2019-01-01 0:00 ` Mark Wielaard [this message]
2019-01-01 0:00 ` Some cherry-picks (Was: [PATCH] bzip2: Fix return value when combining --test,-t and -q.) Federico Mena Quintero
2019-01-01 0:00 ` Releasing bzip2 1.0.7 and 1.1.0 ? Was: [PATCH] bzip2: Fix return value when combining --test,-t and -q Mark Wielaard
2019-01-01 0:00 ` Mark Wielaard
2019-01-01 0:00 ` Federico Mena Quintero
2019-01-01 0:00 ` Mark Wielaard
2019-01-01 0:00 ` Federico Mena Quintero
2019-01-01 0:00 ` Mark Wielaard
2019-01-01 0:00 ` Mark Wielaard
2019-01-01 0:00 ` Federico Mena Quintero
2019-01-01 0:00 ` Mark Wielaard
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=909f618c164a1aee716dac9f6620aa90c5260ece.camel@klomp.org \
--to=mark@klomp.org \
--cc=anibal@debian.org \
--cc=bzip2-devel@sourceware.org \
--cc=federico@gnome.org \
--cc=foka@debian.org \
--cc=santiago@debian.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).