This is very similar to #3592 but with fewer arguments.
ASAN report:
==76791==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x61d00001de80 at pc 0x00010546e4ca bp 0x7fff5ab8d5f0 sp 0x7fff5ab8cda0
WRITE of size 16 at 0x61d00001de80 thread T0
#0 0x10546e4c9 in __asan_memcpy (libclang_rt.asan_osx_dynamic.dylib:x86_64h+0x4d4c9)
#1 0x1051c2772 in mrb_funcall_with_block (mruby:x86_64+0x10015a772)
#2 0x1051c7e85 in mrb_f_send (mruby:x86_64+0x10015fe85)
#3 0x1051d8894 in mrb_vm_exec (mruby:x86_64+0x100170894)
#4 0x1051cdad9 in mrb_vm_run (mruby:x86_64+0x100165ad9)
#5 0x105200549 in mrb_top_run (mruby:x86_64+0x100198549)
#6 0x1052d1805 in mrb_load_exec (mruby:x86_64+0x100269805)
#7 0x1052d2615 in mrb_load_file_cxt (mruby:x86_64+0x10026a615)
#8 0x10506a2e6 in main mruby.c:227
#9 0x7fffbbbba234 in start (libdyld.dylib:x86_64+0x5234)
0x61d00001de80 is located 0 bytes to the right of 2048-byte region [0x61d00001d680,0x61d00001de80)
allocated by thread T0 here:
#0 0x105477520 in wrap_realloc (libclang_rt.asan_osx_dynamic.dylib:x86_64h+0x56520)
#1 0x1051628a5 in mrb_default_allocf (mruby:x86_64+0x1000fa8a5)
#2 0x1050e3be8 in mrb_realloc_simple gc.c:202
#3 0x1050e42ce in mrb_realloc gc.c:216
#4 0x1050e4d53 in mrb_malloc gc.c:237
#5 0x1050e4ded in mrb_calloc gc.c:255
#6 0x1051c4a02 in stack_init (mruby:x86_64+0x10015ca02)
#7 0x1051c1bd7 in mrb_funcall_with_block (mruby:x86_64+0x100159bd7)
#8 0x1051c155a in mrb_funcall_with_block (mruby:x86_64+0x10015955a)
#9 0x1051c0d47 in mrb_funcall_argv (mruby:x86_64+0x100158d47)
#10 0x1050a8045 in mrb_obj_new (mruby:x86_64+0x100040045)
#11 0x1050ccb9d in mrb_exc_new_str (mruby:x86_64+0x100064b9d)
#12 0x1050d6967 in mrb_init_exception (mruby:x86_64+0x10006e967)
#13 0x105107990 in mrb_init_core (mruby:x86_64+0x10009f990)
#14 0x10516283e in mrb_open_core (mruby:x86_64+0x1000fa83e)
#15 0x105162a0c in mrb_open_allocf (mruby:x86_64+0x1000faa0c)
#16 0x1051629d7 in mrb_open (mruby:x86_64+0x1000fa9d7)
#17 0x1050691f8 in main mruby.c:171
#18 0x7fffbbbba234 in start (libdyld.dylib:x86_64+0x5234)
SUMMARY: AddressSanitizer: heap-buffer-overflow (libclang_rt.asan_osx_dynamic.dylib:x86_64h+0x4d4c9) 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
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
==76791==ABORTING
Abort trap: 6
The following input demonstrates a crash:
This is very similar to #3592 but with fewer arguments.
ASAN report:
This issue was reported by https://hackerone.com/ssarong
The text was updated successfully, but these errors were encountered: