decompress_bunzip2: off by one in get_next_block()

"origPtr" is used as an offset into the bd->dbuf[] array.  That array is
allocated in start_bunzip() and has "bd->dbufSize" number of elements so
the test here should be >= instead of >.

Later we check "origPtr" again before using it as an offset so I don't
know if this bug can be triggered in real life.

Fixes: bc22c17e12 ('bzip2/lzma: library support for gzip, bzip2 and lzma decompression')
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Cc: Alain Knaff <alain@knaff.lu>
Cc: Yinghai Lu <yinghai@kernel.org>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This commit is contained in:
Dan Carpenter 2014-12-12 16:58:05 -08:00 committed by Linus Torvalds
parent ec72c666fb
commit b5c8afe5be
1 changed files with 1 additions and 1 deletions

View File

@ -184,7 +184,7 @@ static int INIT get_next_block(struct bunzip_data *bd)
if (get_bits(bd, 1)) if (get_bits(bd, 1))
return RETVAL_OBSOLETE_INPUT; return RETVAL_OBSOLETE_INPUT;
origPtr = get_bits(bd, 24); origPtr = get_bits(bd, 24);
if (origPtr > dbufSize) if (origPtr >= dbufSize)
return RETVAL_DATA_ERROR; return RETVAL_DATA_ERROR;
/* mapping table: if some byte values are never used (encoding things /* mapping table: if some byte values are never used (encoding things
like ascii text), the compression code removes the gaps to have fewer like ascii text), the compression code removes the gaps to have fewer