From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:40069) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WhLBA-00014L-C4 for qemu-devel@nongnu.org; Mon, 05 May 2014 11:51:50 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WhLB3-0005q6-Kz for qemu-devel@nongnu.org; Mon, 05 May 2014 11:51:44 -0400 Received: from mx1.redhat.com ([209.132.183.28]:63055) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WhLB3-0005pn-DG for qemu-devel@nongnu.org; Mon, 05 May 2014 11:51:37 -0400 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s45FpZKt004777 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 5 May 2014 11:51:35 -0400 Message-ID: <5367B384.5080407@redhat.com> Date: Mon, 05 May 2014 17:51:32 +0200 From: Max Reitz MIME-Version: 1.0 References: <1399174300-27583-1-git-send-email-mreitz@redhat.com> <20140505093615.GD3317@noname.str.redhat.com> In-Reply-To: <20140505093615.GD3317@noname.str.redhat.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH] qcow2: Fix alloc_clusters_noref() overflow detection List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf Cc: qemu-devel@nongnu.org, Stefan Hajnoczi On 05.05.2014 11:36, Kevin Wolf wrote: > Am 04.05.2014 um 05:31 hat Max Reitz geschrieben: >> If the very first allocation has a length of 0, the free_cluster_index >> is still 0 after the for loop, which means that subtracting one from i= t >> will underflow and signal an invalid range of clusters by returning >> -EFBIG. However, there is no such range, as its length is 0. >> >> Fix this by preventing underflows on free_cluster_index during the >> check. >> >> Signed-off-by: Max Reitz > Heh, I wondered about this when I reviewed that other patch, and came t= o > the conclusion that it probably doesn't happen. Did you find a case > where it does happen in fact? Yes, deleting the last internal snapshot results in a 0-byte allocation=20 for the new (empty) snapshot table. If this is the first allocation=20 after an image has been opened (which is the case for qemu-img snapshot=20 -d), you'll receive the =93File too big=94 error message (which confused = me=20 quite a bit at first, as I wasn't specifically testing this series). Max > Anyway, this can't hurt: > > Reviewed-by: Kevin Wolf