On Tue, Nov 03, 2015 at 04:18:44AM -0800, Lloyd Fournier wrote:
> # New Ticket Created by Lloyd Fournier
> # Please include the string: [perl #126551]
> # in the subject line of all future correspondence about this issue.
> # <URL: https://rt.perl.org/Ticket/Display.html?id=126551 >
>
>
> # Exporter1.pm
> multi foo { }
>
> sub EXPORT {
> Hash.new('&foo' => &foo) #Map.new doesn't cause it.
> }
> ---
> # Exporter2.pm
> multi foo is export { }
> ---
> # main.pl
> use Exporter1;
> use Exporter2;
>
> #! Segmentation fault
Score!
=================================================================
==13267==ERROR: AddressSanitizer: heap-buffer-overflow on address
0x60300023e2c8 at pc 0x7fa2e35f4498 bp 0x7fff11d85020 sp 0x7fff11d85018
READ of size 8 at 0x60300023e2c8 thread T0
#0 0x7fa2e35f4497 in get_attribute src/6model/reprs/P6opaque.c:224
#1 0x7fa2e34c413c in MVM_interp_run src/core/interp.c:2462
#2 0x7fa2e37602a3 in MVM_vm_run_file src/moar.c:249
#3 0x401a4f in main src/main.c:191
#4 0x7fa2e2cebd5c in __libc_start_main (/lib64/libc.so.6+0x1ed5c)
#5 0x401058 (/home/nicholas/Sandpit/moar-san/bin/moar+0x401058)
0x60300023e2c8 is located 8 bytes to the left of 24-byte region
[0x60300023e2d0,0x60300023e2e8)
allocated by thread T0 here:
#0 0x7fa2e406a62f in __interceptor_malloc
../../.././libsanitizer/asan/asan_malloc_linux.cc:72
#1 0x7fa2e367c6b5 in MVM_malloc src/core/alloc.h:2
#2 0x7fa2e368fce7 in deserialize_stable src/6model/serialization.c:2413
#3 0x7fa2e369208d in work_loop src/6model/serialization.c:2601
#4 0x7fa2e369291f in MVM_serialization_demand_stable
src/6model/serialization.c:2671
#5 0x7fa2e3679afd in MVM_sc_get_stable src/6model/sc.c:234
#6 0x7fa2e368dba0 in read_object_table_entry src/6model/serialization.c:2114
#7 0x7fa2e3693c86 in repossess src/6model/serialization.c:2832
#8 0x7fa2e3694f41 in MVM_serialization_deserialize
src/6model/serialization.c:2990
#9 0x7fa2e34db5f6 in MVM_interp_run src/core/interp.c:3466
#10 0x7fa2e37602a3 in MVM_vm_run_file src/moar.c:249
#11 0x401a4f in main src/main.c:191
#12 0x7fa2e2cebd5c in __libc_start_main (/lib64/libc.so.6+0x1ed5c)
SUMMARY: AddressSanitizer: heap-buffer-overflow src/6model/reprs/P6opaque.c:224
get_attribute
Shadow bytes around the buggy address:
0x0c068003fc00: 00 00 00 02 fa fa 00 00 00 fa fa fa 00 00 00 fa
0x0c068003fc10: fa fa 00 00 00 fa fa fa 00 00 00 00 fa fa 00 00
0x0c068003fc20: 00 00 fa fa 00 00 00 00 fa fa 00 00 00 00 fa fa
0x0c068003fc30: 00 00 00 06 fa fa 00 00 00 06 fa fa 00 00 00 06
0x0c068003fc40: fa fa 00 00 00 fa fa fa 00 00 00 fa fa fa 00 00
=>0x0c068003fc50: 00 fa fa fa 00 00 00 fa fa[fa]00 00 00 fa fa fa
0x0c068003fc60: 00 00 00 fa fa fa 00 00 00 fa fa fa 00 00 00 fa
0x0c068003fc70: fa fa 00 00 00 fa fa fa 00 00 00 fa fa fa 00 00
0x0c068003fc80: 00 fa fa fa 00 00 00 fa fa fa 00 00 00 fa fa fa
0x0c068003fc90: 00 00 00 fa fa fa 00 00 00 fa fa fa 00 00 00 fa
0x0c068003fca0: fa fa 00 00 00 fa fa fa 00 00 00 fa fa fa 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
Contiguous container OOB:fc
ASan internal: fe
==13267==ABORTING
Not a NULL pointer dereference. A more serious bug than that.
Thanks for reporting the bug, and thanks for reducing it down to a really
small case.
Nicholas Clark
