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

[Andrew Morton <akpm@linux-foundation.org>]

On Sat, 12 Sep 2026 14:17:35 -0400 Matt Turner <mattst88@gmail.com> 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@vger.kernel.org

Why is a backport proposed?  Hopefully because downstream users need
this change, but the changelog doesn't tell anyone the reasons why.