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

[Matt Turner]

On Sun, Sep 13, 2026 at 10:49 PM Andrew Morton
<akpm@xxxxxxxxxxxxxxxxxxxx> wrote:
>
> On Sun, 13 Sep 2026 22:18:07 -0400 Matt Turner <mattst88@xxxxxxxxx> wrote:
>
> > On Sun, Sep 13, 2026 at 10:09 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").
> > > >
> > > >
> > > > ...
> > > >
> > > > -                     if (dbufCount+t >= dbufSize)
> > > > +                     if (dbufCount+t > dbufSize)
> > >
> > > Sashiko thinks there's also a potential overflow here which could be
> > > addressed in this patch.
> > >
> > >         https://sashiko.dev/#/patchset/20260912-b4-bunzip2-blocksize-fix-v1-1-c7384bbfc954@xxxxxxxxx
> >
> > What's the appropriate flow to/from busybox (from which this code
> > originates)? Apparently we don't sync from busybox, but do we want to
> > avoid divergences?
>
> I'm not aware of any such process for any of the lib/ material which
> mirrors some userspace project.  So I guess it's an ad-hoc "send them
> an email" thing.  There's clearly risk that if we accept a new drop
> from upstream, such kernel-first fixes will get lost :(

Okay, thanks. I'll investigate the Sashiko report and follow up with
busybox upstream and then circle back to LKML if there's something we
need to address here.