[4.11 Regression] 64-bit process gets AT_BASE in the first 4 GB if exec'ed from 32-bit process

[Alexey Izbyshev <izbyshev@xxxxxxxxx>]

Hello everyone,

I've discovered the following strange behavior of a 4.15.13-based kernel 
(bisected to
 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=1b028f784e8c341e762c264f70dc0ca1418c8b7a 
between 4.11-rc2 and -rc3 thanks to Alexander Monakov).

I've reported it as 
"https://bugzilla.kernel.org/show_bug.cgi?id=199739";.

$ cat wrap.c
#include <unistd.h>

int main(int argc, char *argv[]) {
  execvp(argv[1], &argv[1]);
  return 127;
}

$ gcc wrap.c -o wrap
$ LD_SHOW_AUXV=1 ./wrap ./wrap true |& grep AT_BASE
AT_BASE:         0x7f63b8309000
AT_BASE:         0x7faec143c000
AT_BASE:         0x7fbdb25fa000

$ gcc -m32 wrap.c -o wrap32
$ LD_SHOW_AUXV=1 ./wrap32 ./wrap true |& grep AT_BASE
AT_BASE:         0xf7eff000
AT_BASE:         0xf7cee000
AT_BASE:         0x7f8b9774e000

On kernels before the referenced commit the second AT_BASE is at the 
same range as the third one.

The consequences:

1) It breaks ASAN

$ gcc -fsanitize=address wrap.c -o wrap-asan
$ ./wrap32 ./wrap-asan true
==1217==Shadow memory range interleaves with an existing memory mapping. 
ASan cannot proceed correctly. ABORTING.
==1217==ASan shadow was supposed to be located in the 
[0x00007fff7000-0x10007fff7fff] range.
==1217==Process memory map follows:
        0x000000400000-0x000000401000   
/home/izbyshev/test/gcc/asan-exec-from-32bit/wrap-asan
        0x000000600000-0x000000601000   
/home/izbyshev/test/gcc/asan-exec-from-32bit/wrap-asan
        0x000000601000-0x000000602000   
/home/izbyshev/test/gcc/asan-exec-from-32bit/wrap-asan
        0x0000f7dbd000-0x0000f7de2000   /lib64/ld-2.27.so
        0x0000f7fe2000-0x0000f7fe3000   /lib64/ld-2.27.so
        0x0000f7fe3000-0x0000f7fe4000   /lib64/ld-2.27.so
        0x0000f7fe4000-0x0000f7fe5000
        0x7fed9abff000-0x7fed9af54000
        0x7fed9af54000-0x7fed9af6b000   /lib64/libgcc_s.so.1
[snip]

2) It doesn't seem to be great for security if an attacker always knows 
that ld.so is going to be mapped into the first 4GB in this case (the 
same thing happens for PIEs as well).

Am I right that this is not the intended behavior?

-Alexey