Re: [PATCH] lib/decompress_bunzip2: fix off-by-one in run-length bounds check

[Andrew Morton]

On Sun, 13 Sep 2026 22:16:16 -0400 Matt Turner <mattst88@xxxxxxxxx> wrote:

> On Sun, Sep 13, 2026 at 10:07 PM Andrew Morton
> <akpm@xxxxxxxxxxxxxxxxxxxx> wrote:
> >
> > On Sat, 12 Sep 2026 14:17:35 -0400 Matt Turner <mattst88@xxxxxxxxx> wrote:
> >
> > > The run-length path rejects a block when dbufCount+t equals dbufSize,
> > > but the loop that follows writes exactly t bytes starting at dbufCount,
> > > so a block that fills the buffer exactly is legal. bzip2 allows it too:
> > > its decompressor bounds a block at 100000 * blockSize100k and checks
> > > that limit per byte appended. Use > instead of >=.
> > >
> > > bzip2's encoder stops filling a block 19 bytes early, so nothing it
> > > produces ever reaches the limit and the bug stays hidden. Compressors
> > > that use the full block size do reach it: an lbzip2 -9 image whose block
> > > ends on a run fails to decode, and a self-extracting kernel built that
> > > way does not boot.
> > >
> > > This code came from busybox, which fixed the same line in 2013 in commit
> > > 932e233a491b ("bunzip2: fix off-by-one check").
> >
> > Thanks.
> >
> > > Fixes: bc22c17e12c1 ("bzip2/lzma: library support for gzip, bzip2 and lzma decompression")
> > > Cc: stable@xxxxxxxxxxxxxxx
> >
> > Why is a backport proposed?  Hopefully because downstream users need
> > this change, but the changelog doesn't tell anyone the reasons why.
> 
> I ran into this because my system uses lbzip2 as /bin/bzip2 -- a
> common thing on Gentoo I believe. As far as I can tell, anyone using
> lbzip2 as their system bzip2 would run into this and it's only because
> it's very uncommon these days to compress a kernel with bzip2 that no
> one has noticed. I only noticed because I was adding support for
> various compression formats on alpha.

OK, thanks.  A real-world i-hit-this is compelling.

> No strong preference for a backport from me. Just thought it would be desirable.

np, I;ll retain the cc:stable.