==35094==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x61d00001de80 at pc 0x00010dda5bbe bp 0x7fff521eb830 sp 0x7fff521eaff0
WRITE of size 16 at 0x61d00001de80 thread T0
#0 0x10dda5bbd in __asan_memcpy (libclang_rt.asan_osx_dynamic.dylib+0x41bbd)
#1 0x10dba039d in value_move (mruby+0x10019539d)
#2 0x10db7b07c in mrb_vm_exec (mruby+0x10017007c)
#3 0x10db71379 in mrb_vm_run (mruby+0x100166379)
#4 0x10dba2b99 in mrb_top_run (mruby+0x100197b99)
#5 0x10dc71665 in mrb_load_exec (mruby+0x100266665)
#6 0x10dc72475 in mrb_load_file_cxt (mruby+0x100267475)
#7 0x10da0d8ca in main mruby.c:232
#8 0x7fffb4357254 in start (libdyld.dylib+0x5254)
0x61d00001de80 is located 0 bytes to the right of 2048-byte region [0x61d00001d680,0x61d00001de80)
allocated by thread T0 here:
#0 0x10ddaef87 in wrap_realloc (libclang_rt.asan_osx_dynamic.dylib+0x4af87)
#1 0x10db06bb5 in mrb_default_allocf (mruby+0x1000fbbb5)
#2 0x10da88068 in mrb_realloc_simple gc.c:201
#3 0x10da8874e in mrb_realloc gc.c:215
#4 0x10da891c3 in mrb_malloc gc.c:236
#5 0x10da8925d in mrb_calloc gc.c:254
#6 0x10db687b2 in stack_init (mruby+0x10015d7b2)
#7 0x10db6571f in mrb_funcall_with_block (mruby+0x10015a71f)
#8 0x10db65097 in mrb_funcall_with_block (mruby+0x10015a097)
#9 0x10db64877 in mrb_funcall_argv (mruby+0x100159877)
#10 0x10da4b735 in mrb_obj_new (mruby+0x100040735)
#11 0x10da7019d in mrb_exc_new_str (mruby+0x10006519d)
#12 0x10da7a7b7 in mrb_init_exception (mruby+0x10006f7b7)
#13 0x10daab990 in mrb_init_core (mruby+0x1000a0990)
#14 0x10db06b4e in mrb_open_core (mruby+0x1000fbb4e)
#15 0x10db06d1c in mrb_open_allocf (mruby+0x1000fbd1c)
#16 0x10db06ce7 in mrb_open (mruby+0x1000fbce7)
#17 0x10da0c647 in main mruby.c:172
#18 0x7fffb4357254 in start (libdyld.dylib+0x5254)
SUMMARY: AddressSanitizer: heap-buffer-overflow (libclang_rt.asan_osx_dynamic.dylib+0x41bbd) in __asan_memcpy
Shadow bytes around the buggy address:
0x1c3a00003b80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x1c3a00003b90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x1c3a00003ba0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x1c3a00003bb0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x1c3a00003bc0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x1c3a00003bd0:[fa]fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x1c3a00003be0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x1c3a00003bf0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x1c3a00003c00: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x1c3a00003c10: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
0x1c3a00003c20: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
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
==35094==ABORTING
Abort trap: 6
The heap vulnerability described in #3440 is present again. It appears that it was re-introduced by this commit: 736be0e
The following input once again demonstrates a crash:
ASAN report:
This issue was reported by https://hackerone.com/sukhoi
The text was updated successfully, but these errors were encountered: