[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH] Fix subtle integer overflow bug in memory API
From: |
Avi Kivity |
Subject: |
Re: [Qemu-devel] [PATCH] Fix subtle integer overflow bug in memory API |
Date: |
Wed, 14 Sep 2011 11:23:25 +0300 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:6.0) Gecko/20110816 Thunderbird/6.0 |
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