asan library fails with Shadow memory range interleaves with an existing memory mapping

Question

When you load lib asan ,then it fails with below error : Shadow memory range interleaves with an existing memory mapping. ASan cannot proceed correctly. ABORTING.

I loaded library using LD_PRELOAD ,then starting the process it fails as above mentioned error.

Thanks in advance.

Jugal

Please check: github.com/google/sanitizers/wiki/AddressSanitizer#faq A1: If you are using shared ASan DSO, try LD_PRELOAD'ing Asan runtime into your program. A2: Otherwise you are probably hitting a known limitation of dynamic runtime. Libasan is initialized at the end of program startup so if some preceeding library initializer did lots of memory allocations memory region required for ASan shadow memory could be occupied by unrelated mappings. – Jugal

still I face issue – Jugal

I mean the same issue on arch linux with hello word program – Cycloplegia

Recently again I face similar issue with same tool, by using -no-pie it was resolved – Jugal

In my case, this error showed up when I ran a C++ program with -fsanitize and valgrind with --leak-check=full. They have to be run separately. – Diplomatic

Answer 1

For anybody else googling for this and ending here: in my case the error was similar (Ubuntu 22.04 / kernel 5.15) and the root cause turned out to be that the program was linked against BOTH libasan.so.6 and libasan.so.8.

The cause for loading both, was invalid compiler settings -- i was accidentally mixing (system default) gcc-11 and newer g++-12.

The compiler was happy, the thing exploded when launching.

It was fixed when i forced with env CC usage of gcc-12.

Chord

Answer 2

I found a cause for this for 32-bit targets that isn't mentioned in the AddressSanitizer FAQ. If your stack size is unlimited (i.e. you've run ulimit -s unlimited), then a huge amount of address space is reserved at the top of the process mapping for the stack to grow into. This means that the dynamic linker, vdso, libasan.so and other shared libraries are loaded at 0x2aaab000 and below (for me on x86) which conflicts with the address range that ASAN wishes to use.

This is not seen often since the default soft stack limit on Linux is 8192 which leaves plenty of address space below the shared libraries for ASAN. The fix is to set a more appropriate stack size limit.

Furcula

Answer 3

The issue may also be caused by having KASLR enabled on Linux, for example with linux-hardened:

https://github.com/google/sanitizers/issues/837

https://github.com/google/sanitizers/issues/820

In this case, switch your kernel from a hardened variant or disable KASLR with the "nokaslr" boot option:

https://github.com/google/sanitizers/issues/820#issuecomment-1162655994

Spitter