From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:42845) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R3kks-00075P-1n for qemu-devel@nongnu.org; Wed, 14 Sep 2011 04:23:43 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R3kkm-0002YO-Dw for qemu-devel@nongnu.org; Wed, 14 Sep 2011 04:23:37 -0400 Received: from mx1.redhat.com ([209.132.183.28]:60162) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R3kkm-0002Xb-4Y for qemu-devel@nongnu.org; Wed, 14 Sep 2011 04:23:32 -0400 Message-ID: <4E70647D.10408@redhat.com> Date: Wed, 14 Sep 2011 11:23:25 +0300 From: Avi Kivity MIME-Version: 1.0 References: <1315983769-8287-1-git-send-email-david@gibson.dropbear.id.au> In-Reply-To: <1315983769-8287-1-git-send-email-david@gibson.dropbear.id.au> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH] Fix subtle integer overflow bug in memory API List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: David Gibson Cc: agraf@suse.de, qemu-devel@nongnu.org On 09/14/2011 10:02 AM, David Gibson wrote: > It is quite common to have a MemoryRegion with size of INT64_MAX. > When processing alias regions in render_memory_region() it's quite > easy to find a case where it will construct a temporary AddrRange with > a non-zero start, and size still of INT64_MAX. When means attempting > to compute the end of such a range as start + size will result in > signed integer overflow. > > This integer overflow means that addrrange_intersects() can > incorrectly report regions as not intersecting when they do. For > example consider the case of address ranges {0x10000000000, > 0x7fffffffffffffff} and {0x10010000000, 0x10000000} where the second > is in fact included completely in the first. Good catch, thanks for digging this out. > This patch rearranges addrrange_intersects() to avoid the integer > overflow, correcting this behaviour. I expect that the bad behaviour can still be triggered, for example by pointing aliases towards the end of very large regions. Not that I expect this to occur in practice. I think we should move towards using __int128 internally. Is there any relevant host which does not support __int128? Meanwhile, applied to memory/core, and will request a pull shortly. -- error compiling committee.c: too many arguments to function