This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug testsuite/63305] ASan reported heap-buffer-overflow in gcc.target/i386/avx256-unaligned-load{store}-7.c


https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63305

--- Comment #2 from Maxim Ostapenko <chefmax at gcc dot gnu.org> ---
Still fails on trunk:

$ ./xgcc -B./
~/workspace/downloads/gcc/gcc/testsuite/gcc.target/i386/avx256-unaligned-load-7.c
-fsanitize=address -O3 -dp -mavx -mavx256-split-unaligned-load -o  /tmp/a.out
-L../x86_64-unknown-linux-gnu/libsanitizer/asan/.libs
-B../x86_64-unknown-linux-gnu/libsanitizer/asan/
-Wl,-R,../x86_64-unknown-linux-gnu/libsanitizer/asan/.libs -fdump-tree-asan

$ /tmp/a.out 
=================================================================
==4263==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60c00000c000
at pc 0x000000400b9c bp 0x7fff6dad1c20 sp 0x7fff6dad1c18
WRITE of size 8 at 0x60c00000c000 thread T0
    #0 0x400b9b in do_test (/tmp/a.out+0x400b9b)
    #1 0x400845 in main (/tmp/a.out+0x400845)
    #2 0x7f13038b976c in __libc_start_main
(/lib/x86_64-linux-gnu/libc.so.6+0x2176c)
    #3 0x400894 (/tmp/a.out+0x400894)

0x60c00000c000 is located 0 bytes to the right of 128-byte region
[0x60c00000bf80,0x60c00000c000)
allocated by thread T0 here:
    #0 0x7f1303ceeaa9 in __interceptor_malloc
/home/max/workspace/downloads/gcc/libsanitizer/asan/asan_malloc_linux.cc:38
    #1 0x40098d in foo (/tmp/a.out+0x40098d)

SUMMARY: AddressSanitizer: heap-buffer-overflow ??:0 do_test
Shadow bytes around the buggy address:
  0x0c187fff97b0: 00 00 00 00 00 00 00 00 fa fa fa fa fa fa fa fa
  0x0c187fff97c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c187fff97d0: fa fa fa fa fa fa fa fa 00 00 00 00 00 00 00 00
  0x0c187fff97e0: 00 00 00 00 00 00 00 00 fa fa fa fa fa fa fa fa
  0x0c187fff97f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x0c187fff9800:[fa]fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c187fff9810: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c187fff9820: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c187fff9830: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c187fff9840: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c187fff9850: 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
  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
  ASan internal:           fe
==4263==ABORTING

$ ./xgcc -v
Using built-in specs.
COLLECT_GCC=./xgcc
Target: x86_64-unknown-linux-gnu
Configured with: /home/max/workspace/downloads/gcc/configure
--enable-languages=c,c++ --disable-bootstrap --prefix=/usr/gcc-5.0.0
--with-local-prefix=/usr/local --enable-gnu-indirect-function --with-fpmath=sse
Thread model: posix
gcc version 5.0.0 20140925 (experimental) (GCC)


At line 36:
  for (i = N; i >= 0; i--)
    {
      *cp++ = str;
      *dp++ = str;
    }


Here cp itself is char **, so we move cp on sizeof (char *) on each loop
iteration. 
Since N == 128 here, we have 129 iterations, so size of array cp points to
should be 129 * sizeof (char *). Correct?


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]