Crash in application's startup code around Asan red zone

43 views
Skip to first unread message

Jeffrey Walton

unread,
Jan 15, 2021, 2:48:18 PM1/15/21
to address-sanitizer
Hi Everyone,

I'm testing an Asan instrumented build of Bash. Bash and all dependencies have been instrumented. I'm working on Ubuntu 20.04 x86_64 fully patched. It has gcc (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0.

All of the executables and shared objects were built with  CFLAGS/CXXFLAGS of -fsanitize=address and -fno-omit-frame-pointer. LDFLAGS includes -fno-lto. (I tried both with and without LTO).

Bash is crashing in startup code. It looks like Asan is trying to setup a red zone:

   shr    $0x3,%r15
   ===> movl   $0xf1f1f1f1,0x7fff8000(%r15)
        movl   $0xf3f3f304,0x7fff8004(%r15)

r15 is 0xffffffffbc0. The effective address of 0x7fff8000(0xffffffffbc0) does seem to be a bit sideways.

Does anyone know where to go from here?

-----

(gdb) r
...
Program received signal SIGSEGV, Segmentation fault.
0x000055555578cb83 in internal_malloc (n=n@entry=0x20, file=file@entry=0x0,
    line=line@entry=0x0, flags=<optimized out>) at malloc.c:820
820    in malloc.c
(gdb) disass
Dump of assembler code for function internal_malloc:
   0x000055555578cb20 <+0>:    push   %rbp
   0x000055555578cb21 <+1>:    mov    %rsp,%rbp
   0x000055555578cb24 <+4>:    push   %r15
   0x000055555578cb26 <+6>:    lea    -0x90(%rbp),%rcx
   0x000055555578cb2d <+13>:    push   %r14
   0x000055555578cb2f <+15>:    mov    %rsi,%r14
   0x000055555578cb32 <+18>:    push   %r13
   0x000055555578cb34 <+20>:    mov    %rdi,%r13
   0x000055555578cb37 <+23>:    push   %r12
   0x000055555578cb39 <+25>:    push   %rbx
   0x000055555578cb3a <+26>:    sub    $0xa8,%rsp
   0x000055555578cb41 <+33>:    mov    0x6d2e8(%rip),%rax        # 0x5555557f9e30
   0x000055555578cb48 <+40>:    mov    %edx,-0xa0(%rbp)
   0x000055555578cb4e <+46>:    mov    (%rax),%edx
   0x000055555578cb50 <+48>:    mov    %rcx,-0x98(%rbp)
   0x000055555578cb57 <+55>:    test   %edx,%edx
   0x000055555578cb59 <+57>:    jne    0x55555578d7cf <internal_malloc+3247>
   0x000055555578cb5f <+63>:    lea    0x4856a(%rip),%rax        # 0x5555557d50d0
   0x000055555578cb66 <+70>:    mov    %rax,0x8(%rcx)
   0x000055555578cb6a <+74>:    lea    -0x51(%rip),%rax        # 0x55555578cb20 --Type <RET> for more, q to quit, c to continue without paging--
<internal_malloc>
   0x000055555578cb71 <+81>:    movq   $0x41b58ab3,(%rcx)
   0x000055555578cb78 <+88>:    mov    %rax,0x10(%rcx)
   0x000055555578cb7c <+92>:    mov    %rcx,%r15
   0x000055555578cb7f <+95>:    shr    $0x3,%r15
=> 0x000055555578cb83 <+99>:    movl   $0xf1f1f1f1,0x7fff8000(%r15)
   0x000055555578cb8e <+110>:    movl   $0xf3f3f304,0x7fff8004(%r15)
   0x000055555578cb99 <+121>:    mov    0xc6261(%rip),%ebx        # 0x555555852e00 <pagesz>
   0x000055555578cb9f <+127>:    lea    0x60(%rcx),%r8
   0x000055555578cba3 <+131>:    mov    %fs:0x28,%rax
   0x000055555578cbac <+140>:    mov    %rax,-0x38(%rbp)
   0x000055555578cbb0 <+144>:    xor    %eax,%eax
   0x000055555578cbb2 <+146>:    test   %ebx,%ebx
   0x000055555578cbb4 <+148>:    je     0x55555578d3c0 <internal_malloc+2208>
   0x000055555578cbba <+154>:    lea    0x23(%r13),%rsi
   0x000055555578cbbe <+158>:    sar    %ebx
   0x000055555578cbc0 <+160>:    and    $0xfffffffffffffff0,%rsi
   0x000055555578cbc4 <+164>:    movslq %ebx,%rbx
   0x000055555578cbc7 <+167>:    cmp    %rbx,%rsi
   0x000055555578cbca <+170>:    jg     0x55555578d100 <internal_malloc+1504>
   0x000055555578cbd0 <+176>:    mov    $0x10,%eax
   0x000055555578cbd5 <+181>:    mov    $0x1,%ebx
   ...

(gdb) info registers
rax            0x55555578cb20      0x55555578cb20
rbx            0x0                 0x0
rcx            0x7fffffffde00      0x7fffffffde00
rdx            0x0                 0x0
rsi            0x0                 0x0
rdi            0x20                0x20
rbp            0x7fffffffde90      0x7fffffffde90
rsp            0x7fffffffddc0      0x7fffffffddc0
r8             0x0                 0x0
r9             0x1                 0x1
r10            0x7ffff7438b0f      0x7ffff7438b0f
r11            0x55555578e5e0      0x55555578e5e0
r12            0x20                0x20
r13            0x20                0x20
r14            0x0                 0x0
r15            0xffffffffbc0       0xffffffffbc0
rip            0x55555578cb83      0x55555578cb83 <internal_malloc+99>
eflags         0x10206             [ PF IF RF ]
cs             0x33                0x33
ss             0x2b                0x2b
ds             0x0                 0x0
es             0x0                 0x0
fs             0x0                 0x0



Evgenii Stepanov

unread,
Jan 15, 2021, 2:57:53 PM1/15/21
to address-sanitizer
0x7fff8000(0xffffffffbc0) looks fine - it's a shadow address for ~near top of the main thread stack. Perhaps ASan did not initialize in time? What's the backtrace of the crash? Try a breakpoint on __asan_init. Try running with ASAN_OPTIONS=verbosity=2,debug=1, it should print the memory layout.


--
You received this message because you are subscribed to the Google Groups "address-sanitizer" group.
To unsubscribe from this group and stop receiving emails from it, send an email to address-saniti...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/address-sanitizer/0752f970-ec19-4aab-8ca1-c4c6b3c1e1a2n%40googlegroups.com.

Jeffrey Walton

unread,
Jan 15, 2021, 3:29:10 PM1/15/21
to address-sanitizer
Thanks Evgeniy,

Before I run under GDB, I perform:

    set env LD_PRELOAD /usr/lib/x86_64-linux-gnu/libasan.so.5

> What's the backtrace of the crash?

Here is the backtrace:

(gdb) r
...
Program received signal SIGSEGV, Segmentation fault.
0x000055555578cb83 in internal_malloc (n=n@entry=0x20, file=file@entry=0x0,
    line=line@entry=0x0, flags=<optimized out>) at malloc.c:820
820    malloc.c: No such file or directory.
(gdb) bt full
#0  0x000055555578cb83 in internal_malloc (n=n@entry=0x20,
    file=file@entry=0x0, line=line@entry=0x0, flags=<optimized out>)
    at malloc.c:820
        p = <optimized out>
        nunits = <optimized out>
        m = <optimized out>
        z = <optimized out>
        nbytes = <optimized out>
        mg = <optimized out>
#1  0x000055555578e5fe in internal_calloc (flags=0x0, line=0x0, file=0x0,
    s=0x20, n=0x1) at malloc.c:1322
        total = 0x20
        result = <optimized out>
        total = <optimized out>
        result = <optimized out>
#2  calloc (n=n@entry=0x1, s=s@entry=0x20) at malloc.c:1472
No locals.
#3  0x00007ffff7439c05 in _dlerror_run (
    operate=operate@entry=0x7ffff7439490 <dlsym_doit>,
    args=args@entry=0x7fffffffdef0) at dlerror.c:148
        result = <optimized out>
#4  0x00007ffff7439525 in __dlsym (handle=<optimized out>,
    name=0x7ffff76f28c7 "mmap") at dlsym.c:70

--Type <RET> for more, q to quit, c to continue without paging--
        args = {handle = 0xffffffffffffffff, name = 0x7ffff76f28c7 "mmap",
          who = 0x7ffff76d2c19, sym = 0x0}
        result = <optimized out>
#5  0x00007ffff76d2c19 in ?? () from /usr/lib/x86_64-linux-gnu/libasan.so.5
No symbol table info available.
#6  0x00007ffff768db28 in ?? () from /usr/lib/x86_64-linux-gnu/libasan.so.5
No symbol table info available.
#7  0x00007ffff76b1887 in ?? () from /usr/lib/x86_64-linux-gnu/libasan.so.5
No symbol table info available.
#8  0x00007ffff7fe0ce6 in _dl_init (main_map=0x7ffff7ffe190, argc=0x1,
    argv=0x7fffffffe028, env=0x7fffffffe038) at dl-init.c:104
        addrs = <optimized out>
        cnt = <optimized out>
        preinit_array = <optimized out>
        preinit_array_size = <optimized out>
        i = <optimized out>
#9  0x00007ffff7fd013a in _dl_start_user () from /lib64/ld-linux-x86-64.so.2
        audit_list = 0x0
        _dl_rtld_libname2 = {name = 0x0, next = 0x0, dont_free = 0x0}
        library_path = 0x0
        version_info = 0x0
        load_time = 0xbb757
        _dl_rtld_libname = { ... }

> Perhaps ASan did not initialize in time? Try a breakpoint on __asan_init.
 It looks like __asan_init is being called:

(gdb) r
The program being debugged has been started already.
Start it from the beginning? (y or n) y
...
Breakpoint 2, 0x00007ffff76b1a60 in __asan_init ()
   from /usr/lib/x86_64-linux-gnu/libasan.so.5
(gdb) n
Single stepping until exit from function __asan_init,
which has no line number information.
0x00007ffff76b1730 in ?? () from /usr/lib/x86_64-linux-gnu/libasan.so.5
(gdb) n
Cannot find bounds of current function
(gdb) n
Cannot find bounds of current function
(gdb) c
Continuing.

Program received signal SIGSEGV, Segmentation fault.
0x000055555578cb83 in internal_malloc (n=n@entry=0x20, file=file@entry=0x0,
    line=line@entry=0x0, flags=<optimized out>) at malloc.c:820
820    in malloc.c

I can't find malloc.c in the Bash sources. Cf., https://git.savannah.gnu.org/cgit/bash.git/tree/. I don't know where it is coming from.

Jeff

Jeffrey Walton

unread,
Jan 15, 2021, 3:33:09 PM1/15/21
to address-sanitizer
Thanks again Evgeniy,

> Try running with ASAN_OPTIONS=verbosity=2,debug=1, it should print the memory layout.

And here is the run with ASAN_OPTIONS:

(gdb) shell reset
(gdb) set env ASAN_OPTIONS=verbosity=2,debug=1
(gdb) r
...
Starting program: /home/jwalton/ok2delete-asan/bin/bash
==3933371==info->dlpi_name =     info->dlpi_addr = 0x555555554000
==3933371==info->dlpi_name = linux-vdso.so.1    info->dlpi_addr = 0x7ffff7fce000
==3933371==info->dlpi_name = /usr/lib/x86_64-linux-gnu/libasan.so.5    info->dlpi_addr = 0x7ffff7597000
==3933371==AddressSanitizer: libc interceptors initialized
|| `[0x10007fff8000, 0x7fffffffffff]` || HighMem    ||
|| `[0x02008fff7000, 0x10007fff7fff]` || HighShadow ||
|| `[0x00008fff7000, 0x02008fff6fff]` || ShadowGap  ||
|| `[0x00007fff8000, 0x00008fff6fff]` || LowShadow  ||
|| `[0x000000000000, 0x00007fff7fff]` || LowMem     ||
MemToShadow(shadow): 0x00008fff7000 0x000091ff6dff 0x004091ff6e00 0x02008fff6fff
redzone=16
max_redzone=2048
quarantine_size_mb=256M
thread_local_quarantine_size_kb=1024K
malloc_context_size=30
SHADOW_SCALE: 3
SHADOW_GRANULARITY: 8
SHADOW_OFFSET: 0x7fff8000
==3933371==Installed the sigaction for signal 11
==3933371==Installed the sigaction for signal 7
==3933371==Installed the sigaction for signal 8
==3933371==SetCurrentThread: 0x7ffff7576000 for thread 0x7ffff71b1bc0
==3933371==T0: stack [0x7fffff7ff000,0x7ffffffff000) size 0x800000; local=0x7fffffffdf04
==3933371==Using libbacktrace symbolizer.
==3933371==AddressSanitizer Init done
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
==3933371==info->dlpi_name =     info->dlpi_addr = 0x555555554000
==3933371==info->dlpi_name = linux-vdso.so.1    info->dlpi_addr = 0x7ffff7fce000
==3933371==info->dlpi_name = /usr/lib/x86_64-linux-gnu/libasan.so.5    info->dlpi_addr = 0x7ffff7597000


Program received signal SIGSEGV, Segmentation fault.
0x000055555578cb83 in internal_malloc (n=n@entry=0x20, file=file@entry=0x0,
    line=line@entry=0x0, flags=<optimized out>) at malloc.c:820
820    in malloc.c
(gdb)

Jeff

On Friday, January 15, 2021 at 2:57:53 PM UTC-5 Evgeniy Stepanov wrote:

Evgenii Stepanov

unread,
Jan 15, 2021, 3:39:01 PM1/15/21
to address-sanitizer
> || `[0x02008fff7000, 0x10007fff7fff]` || HighShadow ||
> 0x7fff8000(0xffffffffbc0) == 0x10007fff7bc0

Access is within HighShadow, which should be writable. What does /proc/$PID/maps say?

--
You received this message because you are subscribed to the Google Groups "address-sanitizer" group.
To unsubscribe from this group and stop receiving emails from it, send an email to address-saniti...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/address-sanitizer/8cb8a33b-57ef-4811-a13a-457f1676ff9en%40googlegroups.com.

Jeffrey Walton

unread,
Jan 15, 2021, 3:43:14 PM1/15/21
to address-sanitizer
> What does /proc/$PID/maps say?

(gdb) info inferior
  Num  Description       Executable        
* 1    process 3933371   /home/jwalton/ok2delete-asan/bin/bash

(gdb) shell sudo cat /proc/3933371/maps
555555554000-5555555da000 r--p 00000000 103:02 5123232                   /home/jwalton/ok2delete-asan/bin/bash
5555555da000-55555578f000 r-xp 00086000 103:02 5123232                   /home/jwalton/ok2delete-asan/bin/bash
55555578f000-5555557f4000 r--p 0023b000 103:02 5123232                   /home/jwalton/ok2delete-asan/bin/bash
5555557f4000-5555557fa000 r--p 0029f000 103:02 5123232                   /home/jwalton/ok2delete-asan/bin/bash
5555557fa000-555555843000 rw-p 002a5000 103:02 5123232                   /home/jwalton/ok2delete-asan/bin/bash
555555843000-555555859000 rw-p 00000000 00:00 0                          [heap]
7ffff6c9a000-7ffff6fee000 rw-p 00000000 00:00 0
7ffff6fee000-7ffff6ff1000 r--p 00000000 103:02 8519721                   /lib/x86_64-linux-gnu/libgcc_s.so.1
7ffff6ff1000-7ffff7003000 r-xp 00003000 103:02 8519721                   /lib/x86_64-linux-gnu/libgcc_s.so.1
7ffff7003000-7ffff7007000 r--p 00015000 103:02 8519721                   /lib/x86_64-linux-gnu/libgcc_s.so.1
7ffff7007000-7ffff7008000 r--p 00018000 103:02 8519721                   /lib/x86_64-linux-gnu/libgcc_s.so.1
7ffff7008000-7ffff7009000 rw-p 00019000 103:02 8519721                   /lib/x86_64-linux-gnu/libgcc_s.so.1
7ffff7009000-7ffff7018000 r--p 00000000 103:02 8521725                   /lib/x86_64-linux-gnu/libm-2.31.so
7ffff7018000-7ffff70bf000 r-xp 0000f000 103:02 8521725                   /lib/x86_64-linux-gnu/libm-2.31.so
7ffff70bf000-7ffff7156000 r--p 000b6000 103:02 8521725                   /lib/x86_64-linux-gnu/libm-2.31.so
7ffff7156000-7ffff7157000 r--p 0014c000 103:02 8521725                   /lib/x86_64-linux-gnu/libm-2.31.so
7ffff7157000-7ffff7158000 rw-p 0014d000 103:02 8521725                   /lib/x86_64-linux-gnu/libm-2.31.so
7ffff7158000-7ffff715b000 r--p 00000000 103:02 8521743                   /lib/x86_64-linux-gnu/librt-2.31.so
7ffff715b000-7ffff715f000 r-xp 00003000 103:02 8521743                   /lib/x86_64-linux-gnu/librt-2.31.so
7ffff715f000-7ffff7160000 r--p 00007000 103:02 8521743                   /lib/x86_64-linux-gnu/librt-2.31.so
7ffff7160000-7ffff7161000 ---p 00008000 103:02 8521743                   /lib/x86_64-linux-gnu/librt-2.31.so
7ffff7161000-7ffff7162000 r--p 00008000 103:02 8521743                   /lib/x86_64-linux-gnu/librt-2.31.so
7ffff7162000-7ffff7163000 rw-p 00009000 103:02 8521743                   /lib/x86_64-linux-gnu/librt-2.31.so
7ffff7163000-7ffff7165000 rw-p 00000000 00:00 0
7ffff7165000-7ffff718a000 r--p 00000000 103:02 8521723                   /lib/x86_64-linux-gnu/libc-2.31.so
7ffff718a000-7ffff7302000 r-xp 00025000 103:02 8521723                   /lib/x86_64-linux-gnu/libc-2.31.so
7ffff7302000-7ffff734c000 r--p 0019d000 103:02 8521723                   /lib/x86_64-linux-gnu/libc-2.31.so
7ffff734c000-7ffff734d000 ---p 001e7000 103:02 8521723                   /lib/x86_64-linux-gnu/libc-2.31.so
7ffff734d000-7ffff7350000 r--p 001e7000 103:02 8521723                   /lib/x86_64-linux-gnu/libc-2.31.so
7ffff7350000-7ffff7353000 rw-p 001ea000 103:02 8521723                   /lib/x86_64-linux-gnu/libc-2.31.so
7ffff7353000-7ffff7357000 rw-p 00000000 00:00 0
7ffff7357000-7ffff735e000 r--p 00000000 103:02 8521741                   /lib/x86_64-linux-gnu/libpthread-2.31.so
7ffff735e000-7ffff736f000 r-xp 00007000 103:02 8521741                   /lib/x86_64-linux-gnu/libpthread-2.31.so
7ffff736f000-7ffff7374000 r--p 00018000 103:02 8521741                   /lib/x86_64-linux-gnu/libpthread-2.31.so
7ffff7374000-7ffff7375000 r--p 0001c000 103:02 8521741                   /lib/x86_64-linux-gnu/libpthread-2.31.so
7ffff7375000-7ffff7376000 rw-p 0001d000 103:02 8521741                   /lib/x86_64-linux-gnu/libpthread-2.31.so
7ffff7376000-7ffff737a000 rw-p 00000000 00:00 0
7ffff737a000-7ffff73ad000 r--p 00000000 103:02 5126888                   /home/jwalton/ok2delete-asan/lib/libtinfow.so.6.1
7ffff73ad000-7ffff73e7000 r-xp 00033000 103:02 5126888                   /home/jwalton/ok2delete-asan/lib/libtinfow.so.6.1
7ffff73e7000-7ffff7413000 r--p 0006d000 103:02 5126888                   /home/jwalton/ok2delete-asan/lib/libtinfow.so.6.1
7ffff7413000-7ffff7414000 ---p 00099000 103:02 5126888                   /home/jwalton/ok2delete-asan/lib/libtinfow.so.6.1
7ffff7414000-7ffff7418000 r--p 00099000 103:02 5126888                   /home/jwalton/ok2delete-asan/lib/libtinfow.so.6.1
7ffff7418000-7ffff7437000 rw-p 0009d000 103:02 5126888                   /home/jwalton/ok2delete-asan/lib/libtinfow.so.6.1
7ffff7437000-7ffff7438000 rw-p 00000000 00:00 0
7ffff7438000-7ffff7439000 r--p 00000000 103:02 8521724                   /lib/x86_64-linux-gnu/libdl-2.31.so
7ffff7439000-7ffff743b000 r-xp 00001000 103:02 8521724                   /lib/x86_64-linux-gnu/libdl-2.31.so
7ffff743b000-7ffff743c000 r--p 00003000 103:02 8521724                   /lib/x86_64-linux-gnu/libdl-2.31.so
7ffff743c000-7ffff743d000 r--p 00003000 103:02 8521724                   /lib/x86_64-linux-gnu/libdl-2.31.so
7ffff743d000-7ffff743e000 rw-p 00004000 103:02 8521724                   /lib/x86_64-linux-gnu/libdl-2.31.so
7ffff745a000-7ffff7460000 rw-p 00000000 00:00 0
7ffff7460000-7ffff7477000 r--p 00000000 103:02 5122956                   /home/jwalton/ok2delete-asan/lib/libiconv.so.2.6.1
7ffff7477000-7ffff74ac000 r-xp 00017000 103:02 5122956                   /home/jwalton/ok2delete-asan/lib/libiconv.so.2.6.1
7ffff74ac000-7ffff7586000 r--p 0004c000 103:02 5122956                   /home/jwalton/ok2delete-asan/lib/libiconv.so.2.6.1
7ffff7586000-7ffff7587000 ---p 00126000 103:02 5122956                   /home/jwalton/ok2delete-asan/lib/libiconv.so.2.6.1
7ffff7587000-7ffff7589000 r--p 00126000 103:02 5122956                   /home/jwalton/ok2delete-asan/lib/libiconv.so.2.6.1
7ffff7589000-7ffff7597000 rw-p 00128000 103:02 5122956                   /home/jwalton/ok2delete-asan/lib/libiconv.so.2.6.1
7ffff7597000-7ffff75b9000 r--p 00000000 103:02 14427705                  /usr/lib/x86_64-linux-gnu/libasan.so.5.0.0
7ffff75b9000-7ffff76e7000 r-xp 00022000 103:02 14427705                  /usr/lib/x86_64-linux-gnu/libasan.so.5.0.0
7ffff76e7000-7ffff771c000 r--p 00150000 103:02 14427705                  /usr/lib/x86_64-linux-gnu/libasan.so.5.0.0
7ffff771c000-7ffff771d000 ---p 00185000 103:02 14427705                  /usr/lib/x86_64-linux-gnu/libasan.so.5.0.0
7ffff771d000-7ffff7720000 r--p 00185000 103:02 14427705                  /usr/lib/x86_64-linux-gnu/libasan.so.5.0.0
7ffff7720000-7ffff7723000 rw-p 00188000 103:02 14427705                  /usr/lib/x86_64-linux-gnu/libasan.so.5.0.0
7ffff7723000-7ffff7fcb000 rw-p 00000000 00:00 0
7ffff7fcb000-7ffff7fce000 r--p 00000000 00:00 0                          [vvar]
7ffff7fce000-7ffff7fcf000 r-xp 00000000 00:00 0                          [vdso]
7ffff7fcf000-7ffff7fd0000 r--p 00000000 103:02 8521571                   /lib/x86_64-linux-gnu/ld-2.31.so
7ffff7fd0000-7ffff7ff3000 r-xp 00001000 103:02 8521571                   /lib/x86_64-linux-gnu/ld-2.31.so
7ffff7ff3000-7ffff7ffb000 r--p 00024000 103:02 8521571                   /lib/x86_64-linux-gnu/ld-2.31.so
7ffff7ffb000-7ffff7ffc000 rw-p 00000000 00:00 0
7ffff7ffc000-7ffff7ffd000 r--p 0002c000 103:02 8521571                   /lib/x86_64-linux-gnu/ld-2.31.so
7ffff7ffd000-7ffff7ffe000 rw-p 0002d000 103:02 8521571                   /lib/x86_64-linux-gnu/ld-2.31.so
7ffff7ffe000-7ffff7fff000 rw-p 00000000 00:00 0
7ffffffde000-7ffffffff000 rw-p 00000000 00:00 0                          [stack]
ffffffffff600000-ffffffffff601000 --xp 00000000 00:00 0                  [vsyscall]


...

Evgenii Stepanov

unread,
Jan 15, 2021, 5:03:38 PM1/15/21
to address-sanitizer
I think this "malloc.c" could be a problem. The way control jumped from _dlerror_run to a non-ASan malloc is definitely not right.


--
You received this message because you are subscribed to the Google Groups "address-sanitizer" group.
To unsubscribe from this group and stop receiving emails from it, send an email to address-saniti...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/address-sanitizer/ba516219-1464-41ba-8035-dbf3dccb7426n%40googlegroups.com.

Jeffrey Walton

unread,
Jan 15, 2021, 5:07:14 PM1/15/21
to address-...@googlegroups.com
On Fri, Jan 15, 2021 at 2:57 PM 'Evgenii Stepanov' via
address-sanitizer <address-...@googlegroups.com> wrote:
>
> 0x7fff8000(0xffffffffbc0) looks fine - it's a shadow address for ~near top of the main thread stack. Perhaps ASan did not initialize in time? What's the backtrace of the crash? Try a breakpoint on __asan_init. Try running with ASAN_OPTIONS=verbosity=2,debug=1, it should print the memory layout.

I was able to duplicate this issue on Ubuntu 18.05 x86_64 fully patched.

I've got an easy way to duplicate it, if you want to give it a whirl.
You can really give Asan a thorough testing...

git clone https://github.com/noloader/Build-Scripts
cd Build-Scripts

# One-time setup
./setup-cacerts
./setup-wget

# Build Bash and dependencies with Asan
INSTX_JOBS=5 INSTX_ASAN=1 INSTX_PREFIX=$HOME/ok2delete-asan
<let it build everything under Asan>

# Moment of truth...
$HOME/ok2delete-asan/bin/bash
<crash here>

Jeff

Jeffrey Walton

unread,
Jan 15, 2021, 5:21:16 PM1/15/21
to address-sanitizer
On Friday, January 15, 2021 at 5:03:38 PM UTC-5 Evgeniy Stepanov wrote:
I think this "malloc.c" could be a problem. The way control jumped from _dlerror_run to a non-ASan malloc is definitely not right

Ack.

I asked the Bash folks for some help at "Crash in malloc.c : internal_malloc under Asan", https://lists.gnu.org/archive/html/bug-bash/2021-01/msg00124.html.

Jeff

Jeffrey Walton

unread,
Jan 15, 2021, 6:23:14 PM1/15/21
to address-...@googlegroups.com
On Fri, Jan 15, 2021 at 5:03 PM 'Evgenii Stepanov' via
address-sanitizer <address-...@googlegroups.com> wrote:
>
> I think this "malloc.c" could be a problem. The way control jumped from _dlerror_run to a non-ASan malloc is definitely not right.

I don't see malloc.c in the Bash sources on Savannah. However, there's
one in a site called Fossies at
https://fossies.org/dox/bash-5.1/malloc_8c_source.html#l00817 .

Could this be the cause of the mapping problem on line 848:

/* Silently reject too-large requests. XXX - can increase this if HAVE_MMAP */
if (nunits >= NBUCKETS)
return ((PTR_T) NULL);

Does Asan check for allocation failures and print a message?

Jeff

Jeffrey Walton

unread,
Jan 16, 2021, 3:53:26 AM1/16/21
to address-...@googlegroups.com
On Fri, Jan 15, 2021 at 6:23 PM Jeffrey Walton <nolo...@gmail.com> wrote:
>
> On Fri, Jan 15, 2021 at 5:03 PM 'Evgenii Stepanov' via
> address-sanitizer <address-...@googlegroups.com> wrote:
> >
> > I think this "malloc.c" could be a problem. The way control jumped from _dlerror_run to a non-ASan malloc is definitely not right.
>
> I don't see malloc.c in the Bash sources on Savannah. However, there's
> one in a site called Fossies at
> https://fossies.org/dox/bash-5.1/malloc_8c_source.html#l00817 .
>
> Could this be the cause of the mapping problem on line 848:
>
> /* Silently reject too-large requests. XXX - can increase this if HAVE_MMAP */
> if (nunits >= NBUCKETS)
> return ((PTR_T) NULL);

OK, so I had a little more time to work with this. I started
installing the source code in $prefix/src (and used
-fdebug-prefix-map) so the debugger would work.

The code is failing earlier than the test above. It is failing in prologue code:

Program received signal SIGSEGV, Segmentation fault.
0x00005555556fd300 in internal_malloc (n=n@entry=0x20, file=file@entry=0x0,
line=line@entry=0x0, flags=flags@entry=0x2) at malloc.c:824
824 {
(gdb) list
819 static PTR_T
820 internal_malloc (n, file, line, flags) /* get a block */
821 size_t n;
822 const char *file;
823 int line, flags;
824 {
825 register union mhead *p;
826 register int nunits;
827 register char *m, *z;
828 long nbytes;
(gdb)

Jeff
Reply all
Reply to author
Forward
0 new messages