From: Andrew Morton <akpm@linux-foundation.org>
To: mm-commits@vger.kernel.org,stable@vger.kernel.org,hpa@zytor.com,alain@knaff.lu,mattst88@gmail.com,akpm@linux-foundation.org
Subject: [merged mm-nonmm-stable] lib-decompress_bunzip2-fix-off-by-one-in-run-length-bounds-check.patch removed from -mm tree
Date: Tue, 06 Oct 2026 19:05:06 -0700 [thread overview]
Message-ID: <20261007020506.AB8031F0089C@smtp.kernel.org> (raw)
The quilt patch titled
Subject: lib/decompress_bunzip2: fix off-by-one in run-length bounds check
has been removed from the -mm tree. Its filename was
lib-decompress_bunzip2-fix-off-by-one-in-run-length-bounds-check.patch
This patch was dropped because it was merged into the mm-nonmm-stable branch
of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
------------------------------------------------------
From: Matt Turner <mattst88@gmail.com>
Subject: lib/decompress_bunzip2: fix off-by-one in run-length bounds check
Date: Sat, 12 Sep 2026 14:17:35 -0400
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").
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.
Link: https://lore.kernel.org/20260912-b4-bunzip2-blocksize-fix-v1-1-c7384bbfc954@gmail.com
Fixes: bc22c17e12c1 ("bzip2/lzma: library support for gzip, bzip2 and lzma decompression")
Signed-off-by: Matt Turner <mattst88@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Cc: Alain Knaff <alain@knaff.lu>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: <stable@vger.kernel.org>
---
lib/decompress_bunzip2.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/lib/decompress_bunzip2.c~lib-decompress_bunzip2-fix-off-by-one-in-run-length-bounds-check
+++ a/lib/decompress_bunzip2.c
@@ -439,7 +439,7 @@ got_huff_bits:
array.) */
if (runPos) {
runPos = 0;
- if (dbufCount+t >= dbufSize)
+ if (dbufCount+t > dbufSize)
return RETVAL_DATA_ERROR;
uc = symToByte[mtfSymbol[0]];
_
Patches currently in -mm which might be from mattst88@gmail.com are
reply other threads:[~2026-10-07 2:05 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=20261007020506.AB8031F0089C@smtp.kernel.org \
--to=akpm@linux-foundation.org \
--cc=alain@knaff.lu \
--cc=hpa@zytor.com \
--cc=mattst88@gmail.com \
--cc=mm-commits@vger.kernel.org \
--cc=stable@vger.kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.