Fix subtle integer overflow bug in memory API
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. This patch rearranges addrrange_intersects() to avoid the integer overflow, correcting this behaviour. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Avi Kivity <avi@redhat.com>
This commit is contained in:
parent
44520db10b
commit
d2963631dd
4
memory.c
4
memory.c
@ -55,8 +55,8 @@ static AddrRange addrrange_shift(AddrRange range, int64_t delta)
|
||||
|
||||
static bool addrrange_intersects(AddrRange r1, AddrRange r2)
|
||||
{
|
||||
return (r1.start >= r2.start && r1.start < r2.start + r2.size)
|
||||
|| (r2.start >= r1.start && r2.start < r1.start + r1.size);
|
||||
return (r1.start >= r2.start && (r1.start - r2.start) < r2.size)
|
||||
|| (r2.start >= r1.start && (r2.start - r1.start) < r1.size);
|
||||
}
|
||||
|
||||
static AddrRange addrrange_intersection(AddrRange r1, AddrRange r2)
|
||||
|
Loading…
Reference in New Issue
Block a user