From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:40713) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a3lsH-00029k-EK for qemu-devel@nongnu.org; Tue, 01 Dec 2015 09:25:46 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a3lsG-0003Ds-IE for qemu-devel@nongnu.org; Tue, 01 Dec 2015 09:25:45 -0500 Date: Tue, 1 Dec 2015 16:25:38 +0200 From: "Michael S. Tsirkin" Message-ID: <20151201162529-mutt-send-email-mst@redhat.com> References: <1448979825-24566-1-git-send-email-kwolf@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1448979825-24566-1-git-send-email-kwolf@redhat.com> Subject: Re: [Qemu-devel] [PATCH] qcow2: Fix potential qemu-img check crash on 32 bit hosts List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf Cc: qemu-devel@nongnu.org, qemu-block@nongnu.org, mreitz@redhat.com On Tue, Dec 01, 2015 at 03:23:45PM +0100, Kevin Wolf wrote: > This crash was caught with qemu-iotests test case 138. > > Commit b6d36de already fixed a few 32 bit truncation bugs that could > cause qemu-img check to allocate too little memory and consequently > it would segfault. On 32 bit hosts, there is one more place that needs > to be fixed because size_t was involved in the calculation and is a > 32 bit type there. > > Cc: qemu-stable@nongnu.org > Reported-by: Michael S. Tsirkin > Signed-off-by: Kevin Wolf Tested-by: Michael S. Tsirkin > --- > block/qcow2-refcount.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/block/qcow2-refcount.c b/block/qcow2-refcount.c > index 6e0e5bd..820f412 100644 > --- a/block/qcow2-refcount.c > +++ b/block/qcow2-refcount.c > @@ -1244,7 +1244,7 @@ fail: > /* refcount checking functions */ > > > -static size_t refcount_array_byte_size(BDRVQcow2State *s, uint64_t entries) > +static uint64_t refcount_array_byte_size(BDRVQcow2State *s, uint64_t entries) > { > /* This assertion holds because there is no way we can address more than > * 2^(64 - 9) clusters at once (with cluster size 512 = 2^9, and because > -- > 1.8.3.1