aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorMark Wielaard <mark@klomp.org>2026-05-28 16:15:45 +0200
committerMark Wielaard <mark@klomp.org>2026-05-28 16:53:21 +0200
commit35d122a3df8b0cc4082a4d89fdc6ee99f375fe67 (patch)
tree85c8b047bdc946564788ec4cd44cc8bb976aebc8
parentaf79253677ad98d6dfe11ea315ee9947d86586d3 (diff)
downloadbzip2-35d122a3df8b0cc4082a4d89fdc6ee99f375fe67.tar.gz
bzip2-35d122a3df8b0cc4082a4d89fdc6ee99f375fe67.tar.bz2
bzip2-35d122a3df8b0cc4082a4d89fdc6ee99f375fe67.zip
bzip2recover: Make sure to not process more than BZ_MAX_HANDLED_BLOCKS
There is an off-by-one in the check before calling tooManyBlocks. This causes the scanning loop to run one more time and cause a possible read or write one past the global bStart, bEnd, rbStart and rbEnd buffers. There are no known exploits of this issue and you will need to compile with something like gcc -fsanitize=address (ASAN AddressSanitizer) to observe the faulty read/write. This has been assigned CVE-2026-42250.
-rw-r--r--bzip2recover.c2
1 files changed, 1 insertions, 1 deletions
diff --git a/bzip2recover.c b/bzip2recover.c
index a8131e0..4b1c219 100644
--- a/bzip2recover.c
+++ b/bzip2recover.c
@@ -402,7 +402,7 @@ Int32 main ( Int32 argc, Char** argv )
402 rbEnd[rbCtr] = bEnd[currBlock]; 402 rbEnd[rbCtr] = bEnd[currBlock];
403 rbCtr++; 403 rbCtr++;
404 } 404 }
405 if (currBlock >= BZ_MAX_HANDLED_BLOCKS) 405 if (currBlock >= BZ_MAX_HANDLED_BLOCKS - 1)
406 tooManyBlocks(BZ_MAX_HANDLED_BLOCKS); 406 tooManyBlocks(BZ_MAX_HANDLED_BLOCKS);
407 currBlock++; 407 currBlock++;
408 408