Comment #4 on issue 348 by [email protected]: asan does not always
detect access beyond mmaped page
https://code.google.com/p/address-sanitizer/issues/detail?id=348
Yes, the pages are adjacent to each other, because OS kernel tries to merge
mappings if possible, so that it is only 1 VMA internally:
(print patch)
--- a/page-access-beyond.c.kirr
+++ b/page-access-beyond.c
@@ -27,6 +27,9 @@ int main()
if (page2 == MAP_FAILED)
xabort("mmap2");
+ printf("p1: %p\n", page1);
+ printf("p2: %p\n", page2);
+
page1[0] = 0;
page1[pagesize-1] = 1;
(output)
p1: 0x7f05a5dd8000
p2: 0x7f05a5dd7000
and that's why asan does not complain.
~~~~~~~~
But the point here is that it is still an error - because OS could put
page1 and page2 at any place because mmaps specify addr=NULL which
means "map anywhere.
Merging them is just kernel optimisation which does not work 100% of the
time
(e.g. if page1 was allocated at address space hole of only 1 page - there
will
be no chance for page2 to be allocated adjacent)
I think the solution here would be to one way or another intercept mmap,
in interceptor first allocate 2-pages-larger address space with
map(NULL, PROT_NONE, MAP_NORESERVE, len=orig_len + 2*pagesize)
and then perform original mmap into inside of this address space region with
MAP_FIXED.
This way there will be protective pages before and after valid mapping
and detecting access beyond would work.
Thanks again,
Kirill
--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings
--
You received this message because you are subscribed to the Google Groups
"address-sanitizer" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
