Comment #8 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
I've measured my running firefox:
$ cat /proc/`pidof iceweasel`/maps | wc -l
I think this stat is low exactly because the kernel consolidates adjacent
mappings. For example, Chrome calls mmap() 600+ times during the first
seconds of startup, and many of those calls would've been merged into a
single region.
https://bugzilla.kernel.org/show_bug.cgi?id=67651 gives an idea of how the
number of mappings changes when adjacent mappings with similar permissions
aren't combined.
So if a user creates special program which creates a lot of mappings
he/she should probably be already aware of
/proc/sys/vm/max_map_count
knob and _that_ is the flag to tune to run such a program with additional
mmap sanitizations.
Thanks, I wasn't aware of this. Indeed, sysctl vm.max_map_count=16777216
lets the program create far more mappings (although this probably affects
the performance).
Could you please provide an example?
MAP_FIXED was my first thought. I was also thinking about doing something
like:
ptr = mmap(0, size, ...)
ptr2 = mmap(ptr + size, ...)
, but this isn't guaranteed to work (i.e. is one of the cases you want to
look for), so probably MAP_FIXED is the only interesting case.
On munmap see to which region it belongs, and if original region (which
could be later changed with MAP_FIXED mapping into it, but anyway) was
originally mmaped with red-zone, and we are unmapping adjacent to
red-zone (either part), just adjust the red zone.
Sounds good
And if kernel __NR_mmap is called with correct args directly overcoming
interceptor, it will just unmap some region inside original larger
mapping with red-zones, so red-zones will stay, and since they are mapped
with PROT_NONE, will catch later incorrect read/write access to them. The
only problem here is that red-zone mapping are leaking if unmap is called
directly.
We'll also need to remove the left part of the original larger mapping from
ASan's mappings registry so that further munmap() calls do not attempt to
unmap that part's redzone (I'm talking about the right redzone, although we
can possibly create both).
I now agree mmap() interception won't break much, although may increase
lookup time in the kernel structures handling the mappings.
--
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.
