https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101380
--- Comment #3 from puspmvqyfzxrbytwsu at niwghx dot com ---
Summary of the problem, as far as I understand it now:
The address sanitizer initialisation code invokes the mmap-syscall (syscall
0x9) with the following paramaters:
0x0000600000000000 - the start address of the mapped memory range (MAP_FIXED is
set!)
0x0000040000003000 - length of the mapped memory range
0x0000000000000000 - protection: PROT_NONE: page may not be accessed
0x0000000000004032 - flags: MAP_NORESERVE | MAP_ANONYMOUS | MAP_FIXED |
MAP_PRIVATE
0xFFFFFFFFFFFFFFFF - file descriptor: -1
0x0000000000000000 - offset: 0
So it creates an anonymous mapping in the address range
from 0x0000600000000000 to 0x0000640000003000 (presumably to reserve memory for
the allocator), thereby also discarding any existing mappings into that memory
range (due to MAP_FIXED).
According to my testing, this syscall is always made with the same parameters
from the same call site (and always succeeds) in the above example program
compiled with:
gcc -no-pie -fsanitize=address testcase.c
If that memory range happens to overlap with the running code (due to ASLR),
the program crashes immediately upon return from the syscall due to the
resulting address space corrpution.
Here is the stack trace of the call:
==== stack trace ====
procedure name offset within
procedure (in bytes)
_ZN11__sanitizer13internal_mmapEPvmiiiy +0x8
_ZN11__sanitizer9MmapNamedEPvmiiPKc +0x0
_ZN11__sanitizer20ReservedAddressRange4InitEmPKcm +0x60
_ZN6__asan19InitializeAllocatorERKNS_16AllocatorOptionsE
_ZN6__asanL16AsanInitInternalEv.part.0
_dl_init
==== end of stack trace ====
Maybe the flag MAP_FIXED_NOREPLACE should be used here instead of MAP_FIXED?
That would prevent the syscall from corrupting the address space.
I don't know the implementation, so I don't know why MAP_FIXED is used here in
the first place.
Do you need any additional information for further debugging / fixing this bug?
