[PATCH] D21509: [asan] fix false dynamic-stack-buffer-overflow report with constantly-sized dynamic allocas

[Maxim Ostapenko via llvm-commits]

m.ostapenko added a comment.

Hm, with this patch I got such a strange error:

$ cat test.c

  #include <alloca.h>
  #include <stdio.h>
  #include <string.h>
  
  void f1() {
    char *dynamic_buffer = (char *)alloca(200);
    fprintf(stderr, "dynamic_buffer = %p, dynamic_buffer_end = %p\n", dynamic_buffer, dynamic_buffer + 200);
    dynamic_buffer[2] = 1;
    return;
  }
  
  void f2() {
    char buf[1024];
    fprintf(stderr, "buf = %p, buf_end = %p\n", buf, buf + 1024);
    memset(buf, 'x', 1024);
  }
  
  int main(int argc, const char *argv[]) {
    f1();
    f2();
    fprintf(stderr, "Done.\n");
    return 0;
  }

$ clang -fsanitize=address test.c && ./a.out

  dynamic_buffer = 0x7ffed7c98a80, dynamic_buffer_end = 0x7ffed7c98b48
  =================================================================
  ==15867==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7ffed7c98a82 at pc 0x0000004dbaaa bp 0x7ffed7c98a50 sp 0x7ffed7c98a48
  WRITE of size 1 at 0x7ffed7c98a82 thread T0
      #0 0x4dbaa9 in f1 (/home/max/build/llvm/a.out+0x4dbaa9)
      #1 0x4dbcda in main (/home/max/build/llvm/a.out+0x4dbcda)
      #2 0x7f1a18464ec4 in __libc_start_main /build/eglibc-3GlaMS/eglibc-2.19/csu/libc-start.c:287
      #3 0x418b95 in _start (/home/max/build/llvm/a.out+0x418b95)
  
  Address 0x7ffed7c98a82 is located in stack of thread T0 at offset 34 in frame
      #0 0x4db95f in f1 (/home/max/build/llvm/a.out+0x4db95f)
  
    This frame has 1 object(s):
      [32, 33) '' <== Memory access at offset 34 overflows this variable
  HINT: this may be a false positive if your program uses some custom stack unwind mechanism or swapcontext
        (longjmp and C++ exceptions *are* supported)
  SUMMARY: AddressSanitizer: stack-buffer-overflow (/home/max/build/llvm/a.out+0x4dbaa9) in f1
  Shadow bytes around the buggy address:
    0x10005af8b100: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    0x10005af8b110: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    0x10005af8b120: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    0x10005af8b130: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    0x10005af8b140: 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1
  =>0x10005af8b150:[01]f3 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00
    0x10005af8b160: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    0x10005af8b170: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    0x10005af8b180: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    0x10005af8b190: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    0x10005af8b1a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  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
    Heap right redzone:      fb
    Freed heap region:       fd
    Stack left redzone:      f1
    Stack mid redzone:       f2
    Stack right redzone:     f3
    Stack partial redzone:   f4
    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

It seems that dynamic_buffer wasn't even allocated here.


http://reviews.llvm.org/D21509