On OS X when not re-execing, ASan overwrites already used memory

[ramosian-glider]

Originally reported on Google Code with ID 365

On OS X, since ASan is a dynamic shared library, there are cases when the runtime is
initialized "late". For example when the main executable is not instrumented, but another
library that is loaded later is. When this happens, ASan tries to re-exec with DYLD_INSERT_LIBRARIES
to make sure the interceptors work. However this can either fail (e.g. in a sandbox
where exec is disabled) or one can use allow_reexec=0 to disallow re-exec. In these
cases, the initialization of the shadow memory or the allocator's memory regions can
overwrite an already existing memory. The mmap() call that is used to initialize these
regions doesn't fail when there already is a memory mapping at these locations, instead
it simply overwrites the mappings. This is a known and documented limitation of using
MAP_FIXED. However, the current behavior leads to random crashes and memory corruptions
in these cases. See the attached test case.

What I think we should do is:
1) Add a check whether the memory region is already used before the mmap(), and abort
if it is.
2) Add an abort when a re-exec fails.
3) Remove the "allow_reexec" flag.

Reported by kuba.brecka on 2014-12-18 20:11:11

---

• Attachment: mmap-overwrite.cc

[ramosian-glider]

There already is a check that the shadow memory range does not interleave with the existing
library mappings. It's possible to also check for anonymous mappings as well, but that
might be quite slow.
I think we just need to remove the allow_reexec flag and print a warning suggesting
to manually run with DYLD_INSERT_LIBRARIES if re-exec fails.
Will that cover your use cases?

Reported by ramosian.glider on 2014-12-19 09:45:13

[ramosian-glider]

Adding Project:AddressSanitizer as part of GitHub migration.

Reported by ramosian.glider on 2015-07-30 09:06:35

• Labels added: ProjectAddressSanitizer

[morehouse]

@ramosian-glider: There's been no response from Kuba in 3 years. Do we still want to implement this, or close as won't-fix?