null ptr deref, segfault Perl_newSVpv (sv.c:9218)

[p5pRT]

Migrated from rt.perl.org#129105 (status was 'rejected')

Searchable as RT129105$

[p5pRT]

From @geeknik

Fuzzing Perl v5.25.4-20-gc2f7c0b* with AFL, ASAN and libdislocator.

./perl -e 'unpack+p,w0000000'

==23795==ERROR​: AddressSanitizer​: SEGV on unknown address 0x000000000000 (pc 0x7f648b2aec3a bp 0x7ffd3b494e80 sp 0x7ffd3b494618 T0)
  #0 0x7f648b2aec39 in strlen /build/glibc-uPj9cH/glibc-2.19/string/../sysdeps/x86_64/strlen.S​:76
  #1 0x4abacb in __interceptor_strlen (/root/perl/perl+0x4abacb)
  #2 0x962587 in Perl_newSVpv /root/perl/sv.c​:9218​:5
  #3 0xc547ed in S_unpack_rec /root/perl/pp_pack.c​:1564​:3
  #4 0xc4b955 in Perl_unpackstring /root/perl/pp_pack.c​:835​:12
  #5 0xc61499 in Perl_pp_unpack /root/perl/pp_pack.c​:1839​:11
  #6 0x7f1c63 in Perl_runops_debug /root/perl/dump.c​:2234​:23
  #7 0x5a10a6 in S_run_body /root/perl/perl.c​:2525​:2
  #8 0x5a10a6 in perl_run /root/perl/perl.c​:2448
  #9 0x4de6cd in main /root/perl/perlmain.c​:123​:9
  #10 0x7f648b24eb44 in __libc_start_main /build/glibc-uPj9cH/glibc-2.19/csu/libc-start.c​:287
  #11 0x4de33c in _start (/root/perl/perl+0x4de33c)

AddressSanitizer can not provide additional info.
SUMMARY​: AddressSanitizer​: SEGV /build/glibc-uPj9cH/glibc-2.19/string/../sysdeps/x86_64/strlen.S​:76 strlen
==23795==ABORTING

[p5pRT]

From @cpansprout

On Sat Aug 27 14​:15​:58 2016, brian.carpenter@​gmail.com wrote​:

Fuzzing Perl v5.25.4-20-gc2f7c0b* with AFL, ASAN and libdislocator.

./perl -e 'unpack+p,w0000000'

perlfunc -f unpack​:

  The "p" and "P" formats should be used with care. Since Perl
  has no way of checking whether the value passed to "unpack()"
  corresponds to a valid memory location, passing a pointer value
  that's not known to be valid is likely to have disastrous
  consequences.

I think any tickets concerning crashes with unpack("p", ...) will just have to be rejected as not-a-bug.

--

Father Chrysostomos

[p5pRT]

The RT System itself - Status changed from 'new' to 'open'

[p5pRT]

From @cpansprout

On Sat Aug 27 15​:27​:59 2016, sprout wrote​:

On Sat Aug 27 14​:15​:58 2016, brian.carpenter@​gmail.com wrote​:

Fuzzing Perl v5.25.4-20-gc2f7c0b* with AFL, ASAN and libdislocator.

./perl -e 'unpack+p,w0000000'

perlfunc -f unpack​:

The "p" and "P" formats should be used with care. Since Perl
has no way of checking whether the value passed to "unpack()"
corresponds to a valid memory location, passing a pointer value
that's not known to be valid is likely to have disastrous
consequences.

I think any tickets concerning crashes with unpack("p", ...) will just
have to be rejected as not-a-bug.

Same with​:

$ ./perl -e 'kill 11, $$'
Segmentation fault​: 11

--

Father Chrysostomos

[p5pRT]

From @dcollinsn

Agreed with Father Chrysostomos. This came up a few months ago when I submitted the same ticket. Unpack, kill, -u, and dump are all "supposed to" - or at least allowed to - dump core. Closing - but reopen if you disagree.

--
Respectfully,
Dan Collins

[p5pRT]

@dcollinsn - Status changed from 'open' to 'rejected'