Re: [Qemu-devel] [PATCH] Fix subtle integer overflow bug in memory API

[Avi Kivity <avi@redhat.com>]

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