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

[Matt Turner <mattst88@gmail.com>]

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").

Fixes: bc22c17e12c1 ("bzip2/lzma: library support for gzip, bzip2 and lzma decompression")
Cc: stable@vger.kernel.org
Signed-off-by: Matt Turner <mattst88@gmail.com>
---
lib/decompress_bunzip2: fix off-by-one in run-length bounds check
---
 lib/decompress_bunzip2.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/decompress_bunzip2.c b/lib/decompress_bunzip2.c
index 1288f146661f..aaa75404250e 100644
--- a/lib/decompress_bunzip2.c
+++ b/lib/decompress_bunzip2.c
@@ -439,7 +439,7 @@ static int INIT get_next_block(struct bunzip_data *bd)
 		   array.) */
 		if (runPos) {
 			runPos = 0;
-			if (dbufCount+t >= dbufSize)
+			if (dbufCount+t > dbufSize)
 				return RETVAL_DATA_ERROR;
 
 			uc = symToByte[mtfSymbol[0]];

---
base-commit: 893e11787f78e43b534e252249ac3fff4d1333f8
change-id: 20260912-b4-bunzip2-blocksize-fix-7333376abd40

Best regards,
-- 
Matt Turner <mattst88@gmail.com>