Programs compiled with "-fsanitize=address" crashes with: "Shadow memory range interleaves with an existing memory mapping. ASan cannot proceed correctly. ABORTING."

[Stephen-Seo]

Bug can be reproduced by building the AUR package blender-git with the following patch applied to its PKGBUILD (to make it build in Debug mode):
https://gist.github.com/Stephen-Seo/88b7453a47e38f7cecf26dfde43ecf58

The following appears in the build log at error:
https://gist.github.com/Stephen-Seo/897d12b778ab44c304ae535a23635871

The bug can be reproduced without rebuilding by going into "$srcdir/build/bin/" and running the "datatoc" binary with no arguments within that directory. The source of this file is located at "$srcdir/blender/source/blender/datatoc/datattoc.c".

The datatoc binary builds and runs fine on stock "linux" kernel, but not on "linux-hardened", even if the binary was built when booted into the stock "linux" kernel.

EDIT: The relevant entry in "compile_commands.json" generated by cmake is:

"command": "/usr/bin/cc -DDEBUG -DWITH_ASSERT_ABORT -DWITH_OPENGL -D_DEBUG -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -D__LITTLE_ENDIAN__ -D__MMX__ -D__SSE2__ -D__SSE__  -Wall -Werror=implicit-function-declaration -Werror=return-type -Werror=vla -Wstrict-prototypes -Wmissing-prototypes -Wno-char-subscripts -Wno-unknown-pragmas -Wpointer-arith -Wunused-parameter -Wwrite-strings -Wlogical-op -Wundef -Winit-self -Wmissing-include-dirs -Wno-div-by-zero -Wtype-limits -Wformat-signedness -Wrestrict -Wnonnull -Wabsolute-value -Wuninitialized -Wredundant-decls -Wshadow -Wno-error=unused-but-set-variable -Wimplicit-fallthrough=5  -fopenmp -std=gnu11 -msse -pipe -fPIC -funsigned-char -fno-strict-aliasing -ffp-contract=off -msse2 -fmacro-prefix-map=\"/home/stephen/Git/blender-git/blender/\"=\"\" -fmacro-prefix-map=\"/home/stephen/Git/blender-git/build/\"=\"\" -g -fsanitize=address -fsanitize=bool -fsanitize=bounds -fsanitize=enum -fsanitize=float-cast-overflow -fsanitize=float-divide-by-zero -fsanitize=nonnull-attribute -fsanitize=returns-nonnull-attribute -fsanitize=signed-integer-overflow -fsanitize=undefined -fsanitize=vla-bound -fno-sanitize=alignment  -fsanitize=leak -fsanitize=object-size -o source/blender/datatoc/CMakeFiles/datatoc.dir/datatoc.c.o -c /home/stephen/Git/blender-git/blender/source/blender/datatoc/datatoc.c",

(one may have to change some directory paths to get this to work. Also, this program appears to have no dependencies, so one should be able to compile it directly into an executable instead of an object file.)

[tsautereau-anssi]

Looking at the build log you provided, I guess it's caused by our commit Revert "mm: revert x86_64 and arm64 ELF_ET_DYN_BASE base changes".

[Stephen-Seo]

I tested a basically no-op program:

int main() {
    return 0;
}

If compiled with gcc -fsanitize=address -o test noop_program.c and run, then it will crash. Without the -fsanitize=address it runs fine.

==4336==Shadow memory range interleaves with an existing memory mapping. ASan cannot proceed correctly. ABORTING.
==4336==ASan shadow was supposed to be located in the [0x00007fff7000-0x10007fff7fff] range.
==4336==This might be related to ELF_ET_DYN_BASE change in Linux 4.12.
==4336==See https://github.com/google/sanitizers/issues/856 for possible workarounds.
==4336==Process memory map follows:
	0x045824f83000-0x045824f84000	/home/stephen/temp/test
	0x045824f84000-0x045824f85000	/home/stephen/temp/test
	0x045824f85000-0x045824f86000	/home/stephen/temp/test
	0x045824f86000-0x045824f87000	/home/stephen/temp/test
	0x045824f87000-0x045824f88000	/home/stephen/temp/test
	0x6d57a2700000-0x6d57a2800000	
	0x6d57a2900000-0x6d57a2a00000	
	0x6d57a2b00000-0x6d57a2c00000	
	0x6d57a2d00000-0x6d57a2e00000	
	0x6d57a2f00000-0x6d57a3000000	
	0x6d57a3012000-0x6d57a33a5000	
	0x6d57a33a5000-0x6d57a33a8000	/usr/lib/libgcc_s.so.1
	0x6d57a33a8000-0x6d57a33bf000	/usr/lib/libgcc_s.so.1
	0x6d57a33bf000-0x6d57a33c3000	/usr/lib/libgcc_s.so.1
	0x6d57a33c3000-0x6d57a33c4000	/usr/lib/libgcc_s.so.1
	0x6d57a33c4000-0x6d57a33c5000	/usr/lib/libgcc_s.so.1
	0x6d57a33c5000-0x6d57a33d5000	/usr/lib/libm.so.6
	0x6d57a33d5000-0x6d57a344e000	/usr/lib/libm.so.6
	0x6d57a344e000-0x6d57a34aa000	/usr/lib/libm.so.6
	0x6d57a34aa000-0x6d57a34ab000	/usr/lib/libm.so.6
	0x6d57a34ab000-0x6d57a34ac000	/usr/lib/libm.so.6
	0x6d57a34ac000-0x6d57a3546000	/usr/lib/libstdc++.so.6.0.30
	0x6d57a3546000-0x6d57a365d000	/usr/lib/libstdc++.so.6.0.30
	0x6d57a365d000-0x6d57a36d4000	/usr/lib/libstdc++.so.6.0.30
	0x6d57a36d4000-0x6d57a36e1000	/usr/lib/libstdc++.so.6.0.30
	0x6d57a36e1000-0x6d57a36e2000	/usr/lib/libstdc++.so.6.0.30
	0x6d57a36e2000-0x6d57a36e5000	
	0x6d57a36e5000-0x6d57a3711000	/usr/lib/libc.so.6
	0x6d57a3711000-0x6d57a3889000	/usr/lib/libc.so.6
	0x6d57a3889000-0x6d57a38dd000	/usr/lib/libc.so.6
	0x6d57a38dd000-0x6d57a38de000	/usr/lib/libc.so.6
	0x6d57a38de000-0x6d57a38e1000	/usr/lib/libc.so.6
	0x6d57a38e1000-0x6d57a38e4000	/usr/lib/libc.so.6
	0x6d57a38e4000-0x6d57a38f1000	
	0x6d57a38f1000-0x6d57a3915000	/usr/lib/libasan.so.8.0.0
	0x6d57a3915000-0x6d57a39fe000	/usr/lib/libasan.so.8.0.0
	0x6d57a39fe000-0x6d57a3a33000	/usr/lib/libasan.so.8.0.0
	0x6d57a3a33000-0x6d57a3a37000	/usr/lib/libasan.so.8.0.0
	0x6d57a3a37000-0x6d57a3a3a000	/usr/lib/libasan.so.8.0.0
	0x6d57a3a3a000-0x6d57a3fa0000	
	0x6d57a3fbc000-0x6d57a3fd7000	
	0x6d57a3fd7000-0x6d57a3fdb000	[vvar]
	0x6d57a3fdb000-0x6d57a3fdd000	[vdso]
	0x6d57a3fdd000-0x6d57a3fdf000	/usr/lib/ld-linux-x86-64.so.2
	0x6d57a3fdf000-0x6d57a4006000	/usr/lib/ld-linux-x86-64.so.2
	0x6d57a4006000-0x6d57a4011000	/usr/lib/ld-linux-x86-64.so.2
	0x6d57a4011000-0x6d57a4012000	
	0x6d57a4012000-0x6d57a4014000	/usr/lib/ld-linux-x86-64.so.2
	0x6d57a4014000-0x6d57a4016000	/usr/lib/ld-linux-x86-64.so.2
	0x716d528bc000-0x716d528de000	[stack]
==4336==End of process memory map.

[Bernhard40]

I think this may be expected as the issues with asan were the reason behind reverting the patch.

This is mentioned in revert description

There is a tracking issue on KSPP about working around the problem but no progress so far.

[anthraxx]

@Bernhard40 thanks for filling in the info here.

The mentioned revert and the reason related to ASan expectations/limitations is indeed the culprit why this doesn't work with linux-hardened. This unfortunately is expected until upstream finds a solution to this issue.