Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Crash at startup when compiled with ASan/UBSan #377

Closed
craigbarnes opened this issue Aug 22, 2020 · 2 comments
Closed

Crash at startup when compiled with ASan/UBSan #377

craigbarnes opened this issue Aug 22, 2020 · 2 comments

Comments

@craigbarnes
Copy link

craigbarnes commented Aug 22, 2020

To reproduce:

$ ./autogen.sh
$ ./configure
$ make CFLAGS='-O2 -g -fsanitize=address,undefined -fsanitize-address-use-after-scope -fno-sanitize-recover=all -fno-omit-frame-pointer -fno-common'
$ ./cava -v
cava 0.7.2-13-g6a0ad3e
$ ./cava

=================================================================
==46568==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x6020000005f0 at pc 0x564477b5a988 bp 0x7fffd709e540 sp 0x7fffd709e530
WRITE of size 4 at 0x6020000005f0 thread T0
    #0 0x564477b5a987 in init_terminal_noncurses output/terminal_noncurses.c:78
    #1 0x564477b502bf in main ~/cava/cava.c:568
    #2 0x7f6265fd3151 in __libc_start_main (/usr/lib/libc.so.6+0x28151)
    #3 0x564477b5260d in _start (~/cava/cava+0x2f60d)

0x6020000005f1 is located 0 bytes to the right of 1-byte region [0x6020000005f0,0x6020000005f1)
allocated by thread T0 here:
    #0 0x7f6267132459 in __interceptor_malloc /build/gcc/src/gcc/libsanitizer/asan/asan_malloc_linux.cpp:145
    #1 0x564477b5a42f in init_terminal_noncurses output/terminal_noncurses.c:69
    #2 0x564477b502bf in main ~/cava/cava.c:568
    #3 0x7f6265fd3151 in __libc_start_main (/usr/lib/libc.so.6+0x28151)

SUMMARY: AddressSanitizer: heap-buffer-overflow output/terminal_noncurses.c:78 in init_terminal_noncurses
Shadow bytes around the buggy address:
  0x0c047fff8060: fa fa 04 fa fa fa fd fa fa fa fd fa fa fa fd fa
  0x0c047fff8070: fa fa fd fa fa fa 00 00 fa fa 00 00 fa fa 05 fa
  0x0c047fff8080: fa fa fd fa fa fa fd fa fa fa 00 00 fa fa fd fa
  0x0c047fff8090: fa fa fd fa fa fa fd fa fa fa fd fa fa fa fd fa
  0x0c047fff80a0: fa fa fd fa fa fa fd fd fa fa fd fa fa fa fd fa
=>0x0c047fff80b0: fa fa fd fa fa fa fd fa fa fa 00 00 fa fa[01]fa
  0x0c047fff80c0: fa fa 00 fa fa fa 00 fa fa fa 00 fa fa fa 00 fa
  0x0c047fff80d0: fa fa 00 fa fa fa 00 fa fa fa 00 fa fa fa 00 fa
  0x0c047fff80e0: fa fa 00 fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c047fff80f0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c047fff8100: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:       fa
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
  Shadow gap:              cc
==46568==ABORTING

This was compiled on Arch with GCC 10.2.0 and no config file.

If I add the following to ~/.config/cava/config:

[output]
method = ncurses

...it starts up fine and works as expected, but then LeakSanitizer gives the following error when exiting:

=================================================================
==61113==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 5 byte(s) in 1 object(s) allocated from:
    #0 0x7ff326d02459 in __interceptor_malloc /build/gcc/src/gcc/libsanitizer/asan/asan_malloc_linux.cpp:145
    #1 0x55cb43b00031 in main ~/cava/cava.c:364
    #2 0x7ff325ba3151 in __libc_start_main (/usr/lib/libc.so.6+0x28151)

Direct leak of 4 byte(s) in 1 object(s) allocated from:
    #0 0x7ff326d02639 in __interceptor_calloc /build/gcc/src/gcc/libsanitizer/asan/asan_malloc_linux.cpp:154
    #1 0x7ff326af719f in pa_xmalloc0 (/usr/lib/libpulse.so.0+0xe19f)

SUMMARY: AddressSanitizer: 9 byte(s) leaked in 2 allocation(s).
karlstav added a commit that referenced this issue Aug 23, 2020
karlstav added a commit that referenced this issue Aug 23, 2020
@karlstav
Copy link
Owner

hi @craigbarnes

thanks for the error report, I should consider doing this on the workflows/actions on each commit.

It is a bit strange that I only got heap-buffer-overflow on the spacestring and barstring (allocated on 70 / 74). This was resolved by allocating an extra char. Most likely for termination (?).

But you get it on the framebuffer allocated on line 69. Since I use a variable amount of ANSI control characters in this buffer I allocated a lot of extra bytes for this. But it could be related to the terminal height or width not being detected. what terminal emulator are you using and does cava behave normally when not using ASan/UBSan?

@craigbarnes
Copy link
Author

craigbarnes commented Aug 24, 2020

I only got heap-buffer-overflow on the spacestring and barstring (allocated on 70 / 74)
...
But you get it on the framebuffer allocated on line 69. Since I use a variable amount of ANSI control characters in this buffer I allocated a lot of extra bytes for this.

I didn't look very far into what may have been causing it, but your latest commits seem to fix the heap-buffer-overflow I was getting at startup. FWIW, I just tried running it again with the same commit as before and the allocation was reported as being on line 74 this time. The discrepancy may be something to do with alignment/padding differences in the ASan allocator.

what terminal emulator are you using

I was using foot.

... and does cava behave normally when not using ASan/UBSan?

Yeah, it started up fine without the sanitizers enabled. I just compiled with them for curiosity's sake.

In my experience, ASan has very few false positives though. If it catches something that doesn't otherwise seem to be a problem, it's usually just down to luck; i.e. the system allocator just happened to round up the alloc sizes enough to avoid the overflow.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants