From patchwork Wed Apr 16 13:08:30 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Kevin Wolf X-Patchwork-Id: 339581 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from lists.gnu.org (lists.gnu.org [208.118.235.17]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 6F7B41400B8 for ; Wed, 16 Apr 2014 23:10:53 +1000 (EST) Received: from localhost ([::1]:54559 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WaPc3-0008Pr-7p for incoming@patchwork.ozlabs.org; Wed, 16 Apr 2014 09:10:51 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:51707) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WaPa3-0005BC-JI for qemu-devel@nongnu.org; Wed, 16 Apr 2014 09:08:55 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WaPZx-0006yW-Dx for qemu-devel@nongnu.org; Wed, 16 Apr 2014 09:08:47 -0400 Received: from mx1.redhat.com ([209.132.183.28]:30163) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WaPZx-0006yJ-4k for qemu-devel@nongnu.org; Wed, 16 Apr 2014 09:08:41 -0400 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s3GD8dLx020151 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 16 Apr 2014 09:08:40 -0400 Received: from noname.redhat.com (ovpn-116-41.ams2.redhat.com [10.36.116.41]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s3GD8XOK023879; Wed, 16 Apr 2014 09:08:38 -0400 From: Kevin Wolf To: qemu-devel@nongnu.org Date: Wed, 16 Apr 2014 15:08:30 +0200 Message-Id: <1397653710-22971-4-git-send-email-kwolf@redhat.com> In-Reply-To: <1397653710-22971-1-git-send-email-kwolf@redhat.com> References: <1397653710-22971-1-git-send-email-kwolf@redhat.com> X-Scanned-By: MIMEDefang 2.67 on 10.5.11.12 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 209.132.183.28 Cc: kwolf@redhat.com, stefanha@redhat.com Subject: [Qemu-devel] [PATCH 3/3] block: Catch integer overflow in bdrv_rw_co() X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org Sender: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org Insanely large requests could cause an integer overflow in bdrv_rw_co() while converting sectors to bytes. This patch catches the problem and returns an error (if we hadn't overflown the integer here, bdrv_check_byte_request() would have rejected the request, so we're not breaking anything that was supposed to work before). We actually do have a test case that triggers behaviour where we accidentally let such a request pass, so that it would return success, but read 0 bytes instead of the requested 4 GB. It fails now like it should. If the vdi block driver wants to be able to deal with huge images, it can't read the whole block bitmap at once into memory like it does today, but needs to use a metadata cache like qcow2 does. Signed-off-by: Kevin Wolf --- block.c | 4 ++++ tests/qemu-iotests/084.out | 5 +---- 2 files changed, 5 insertions(+), 4 deletions(-) diff --git a/block.c b/block.c index bcf9dc9..d268ece 100644 --- a/block.c +++ b/block.c @@ -2698,6 +2698,10 @@ static int bdrv_rw_co(BlockDriverState *bs, int64_t sector_num, uint8_t *buf, .iov_len = nb_sectors * BDRV_SECTOR_SIZE, }; + if (nb_sectors < 0 || nb_sectors > INT_MAX / BDRV_SECTOR_SIZE) { + return -EINVAL; + } + qemu_iovec_init_external(&qiov, &iov, 1); return bdrv_prwv_co(bs, sector_num << BDRV_SECTOR_BITS, &qiov, is_write, flags); diff --git a/tests/qemu-iotests/084.out b/tests/qemu-iotests/084.out index e681924..c7120d9 100644 --- a/tests/qemu-iotests/084.out +++ b/tests/qemu-iotests/084.out @@ -4,10 +4,7 @@ QA output created by 084 Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=67108864 Test 1: Maximum size (1024 TB): -image: TEST_DIR/t.IMGFMT -file format: IMGFMT -virtual size: 1024T (1125899905794048 bytes) -cluster_size: 1048576 +qemu-img: Could not open 'TEST_DIR/t.IMGFMT': Could not open 'TEST_DIR/t.IMGFMT': Invalid argument Test 2: Size too large (1024TB + 1) qemu-img: Could not open 'TEST_DIR/t.IMGFMT': Unsupported VDI image size (size is 0x3fffffff10000, max supported is 0x3fffffff00000)