From ef73de2a84a3042c3481c9a521e8e0c756b793f2 Mon Sep 17 00:00:00 2001 From: Dan Carpenter Date: Tue, 3 Feb 2015 15:30:13 +0100 Subject: [PATCH] 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. Signed-off-by: Dan Carpenter Trivial adjustments to make the respective Linux commit b5c8afe5be51078a979d86ae5ae78c4ac948063d apply to Xen. Signed-off-by: Jan Beulich Acked-by: Ian Campbell master commit: 39798e95a954eec660a3f5f21489c30ef78daf6d master date: 2015-01-28 16:50:08 +0100 --- xen/common/bunzip2.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/xen/common/bunzip2.c b/xen/common/bunzip2.c index 2eb70ab6c4..6d6e8b19fd 100644 --- a/xen/common/bunzip2.c +++ b/xen/common/bunzip2.c @@ -174,7 +174,7 @@ static int INIT get_next_block(struct bunzip_data *bd) if (get_bits(bd, 1)) return RETVAL_OBSOLETE_INPUT; origPtr = get_bits(bd, 24); - if (origPtr > dbufSize) + if (origPtr >= dbufSize) return RETVAL_DATA_ERROR; /* mapping table: if some byte values are never used (encoding things like ascii text), the compression code removes the gaps to have fewer -- 2.39.5