From mtowalski@pentest.net.pl

Hello,

I've attached the poc and the asan log.
Tested on git version of perl.

Configure options​:

“./Configure -des -Dusedevel -DDEBUGGING -Dcc=clang -Doptimize=-O2 -Accflags="-fsanitize=address -fsanitize-coverage=edge" -Aldflags="-fsanitize=address -fsanitize-coverage=edge" -Alddlflags=-shared"

Information about configuration​:

Distributor ID​: Ubuntu
Description​: Ubuntu 16.10
Release​: 16.10
Codename​: yakkety
Arch​: x86_64

Best Regards,
Marcin T.

From mtowalski@pentest.net.pl

perl-attempting-ea0-7fd-24d

From mtowalski@pentest.net.pl

perl​: warning​: Setting locale failed.
perl​: warning​: Please check that your locale settings​:
  LANGUAGE = (unset),
  LC_ALL = (unset),
  LC_CTYPE = "UTF-8",
  LANG = "en_US.UTF-8"
  are supported and installed on your system.
perl​: warning​: Falling back to a fallback locale ("en_US.UTF-8").

==29544==ERROR​: AddressSanitizer​: attempting free on address which was not malloc()-ed​: 0x62100000f730 in thread T0
  #0 0x4d1ea0 in __interceptor_cfree.localalias.0 (/home/mtowalski/Fuzzing/Programs/perl-git/perl+0x4d1ea0)
  #1 0x8647fd in Perl_safesysfree /home/mtowalski/Fuzzing/Programs/perl-git/util.c​:388​:2
  #2 0x93724d in Perl_vivify_ref /home/mtowalski/Fuzzing/Programs/perl-git/pp_hot.c​:4368​:2
  #3 0x95d754 in Perl_pp_multideref /home/mtowalski/Fuzzing/Programs/perl-git/pp_hot.c​:2513​:18
  #4 0x85d546 in Perl_runops_debug /home/mtowalski/Fuzzing/Programs/perl-git/dump.c​:2450​:23
  #5 0x5eaf07 in S_run_body /home/mtowalski/Fuzzing/Programs/perl-git/perl.c​:2524​:2
  #6 0x5eaf07 in perl_run /home/mtowalski/Fuzzing/Programs/perl-git/perl.c​:2447
  #7 0x503205 in main /home/mtowalski/Fuzzing/Programs/perl-git/perlmain.c​:123​:9
  #8 0x7f60486943f0 in __libc_start_main /build/glibc-jxM2Ev/glibc-2.24/csu/../csu/libc-start.c​:291
  #9 0x433a89 in _start (/home/mtowalski/Fuzzing/Programs/perl-git/perl+0x433a89)

0x62100000f730 is located 1584 bytes inside of 4080-byte region [0x62100000f100,0x6210000100f0)
allocated by thread T0 here​:
  #0 0x4d2038 in malloc (/home/mtowalski/Fuzzing/Programs/perl-git/perl+0x4d2038)
  #1 0x863661 in Perl_safesysmalloc /home/mtowalski/Fuzzing/Programs/perl-git/util.c​:153​:21

SUMMARY​: AddressSanitizer​: bad-free (/home/mtowalski/Fuzzing/Programs/perl-git/perl+0x4d1ea0) in __interceptor_cfree.localalias.0
==29544==ABORTING

From @arc

Reduction​:

$ ./miniperl -e 'map $p[0][0],@​z=z,@​z=z,@​z=z,@​z=z,@​z=z,@​z= ~9'

==13111==ERROR​: AddressSanitizer​: attempting free on address which was
not malloc()-ed​: 0x62100000f598 in thread T0
  #0 0x10d923939 in wrap_free (libclang_rt.asan_osx_dynamic.dylib+0x46939)
  #1 0x10d246089 in Perl_safesysfree (miniperl+0x1002f0089)
  #2 0x10d30e5ad in Perl_vivify_ref (miniperl+0x1003b85ad)
  #3 0x10d331aaa in Perl_pp_multideref (miniperl+0x1003dbaaa)
  #4 0x10d306462 in Perl_runops_standard (miniperl+0x1003b0462)
  #5 0x10d0358e9 in perl_run (miniperl+0x1000df8e9)
  #6 0x10d73dcbf in main (miniperl+0x1007e7cbf)
  #7 0x7fff924075fc in start (libdyld.dylib+0x35fc)
  #8 0x2 (<unknown module>)

0x62100000f598 is located 1176 bytes inside of 4080-byte region
[0x62100000f100,0x6210000100f0)
allocated by thread T0 here​:
  #0 0x10d923770 in wrap_malloc (libclang_rt.asan_osx_dynamic.dylib+0x46770)
  #1 0x10d245a21 in Perl_safesysmalloc (miniperl+0x1002efa21)
  #2 0x10d3886bb in Perl_newSV_type (miniperl+0x1004326bb)
  #3 0x10cfcf4c1 in Perl_newXS_len_flags (miniperl+0x1000794c1)
  #4 0x10cfd0b9c in Perl_newXS_flags (miniperl+0x10007ab9c)
  #5 0x10d6688b9 in Perl_boot_core_UNIVERSAL (miniperl+0x1007128b9)
  #6 0x10d02f7a3 in perl_parse (miniperl+0x1000d97a3)
  #7 0x10d73dc8c in main (miniperl+0x1007e7c8c)
  #8 0x7fff924075fc in start (libdyld.dylib+0x35fc)
  #9 0x2 (<unknown module>)

SUMMARY​: AddressSanitizer​: bad-free
(libclang_rt.asan_osx_dynamic.dylib+0x46939) in wrap_free
==13111==ABORTING
Abort trap​: 6

I was slightly surprised (a) that the multideref needn't look at the
assigned array to trigger this, and (b) that all the array assignments
are necessary.

My first guess is that this is ultimately stack-not-refcounted, but I
haven't looked into that.

--
Aaron Crane ** http​://aaroncrane.co.uk/

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

From @tonycoz

On Sun, 26 Feb 2017 10​:12​:45 -0800, arc@​aaroncrane.co.uk wrote​:

Reduction​:

$ ./miniperl -e 'map $p[0][0],@​z=z,@​z=z,@​z=z,@​z=z,@​z=z,@​z= ~9'
...
SUMMARY​: AddressSanitizer​: bad-free
(libclang_rt.asan_osx_dynamic.dylib+0x46939) in wrap_free
==13111==ABORTING
Abort trap​: 6

I was slightly surprised (a) that the multideref needn't look at the
assigned array to trigger this, and (b) that all the array assignments
are necessary.

My first guess is that this is ultimately stack-not-refcounted, but I
haven't looked into that.

It's pretty common for stack-not-refcounted bugs to introduce just strange behaviour, with a slight variation required to make it crash, or assert​:

$ ./miniperl -e 'map $p[0][0],@​z=z,@​z=(1..3),@​z= ~9'
miniperl​: sv.c​:6557​: Perl_sv_clear​: Assertion `((svtype)((sv)->sv_flags & 0xff)) != (svtype)0xff' failed.
Aborted

(which is a typical stack-not-refcounted assert().)

Tony

From @iabyn

On Sun, Feb 26, 2017 at 08​:58​:19PM -0800, Tony Cook via RT wrote​:

On Sun, 26 Feb 2017 10​:12​:45 -0800, arc@​aaroncrane.co.uk wrote​:

Reduction​:

$ ./miniperl -e 'map $p[0][0],@​z=z,@​z=z,@​z=z,@​z=z,@​z=z,@​z= ~9'
...
SUMMARY​: AddressSanitizer​: bad-free
(libclang_rt.asan_osx_dynamic.dylib+0x46939) in wrap_free
==13111==ABORTING
Abort trap​: 6

I was slightly surprised (a) that the multideref needn't look at the
assigned array to trigger this, and (b) that all the array assignments
are necessary.

My first guess is that this is ultimately stack-not-refcounted, but I
haven't looked into that.

It's pretty common for stack-not-refcounted bugs to introduce just strange behaviour, with a slight variation required to make it crash, or assert​:

$ ./miniperl -e 'map $p[0][0],@​z=z,@​z=(1..3),@​z= ~9'
miniperl​: sv.c​:6557​: Perl_sv_clear​: Assertion `((svtype)((sv)->sv_flags & 0xff)) != (svtype)0xff' failed.
Aborted

(which is a typical stack-not-refcounted assert().)

It can be reduced even further to

  map $$p, @​z=1, @​z=2;

The second assignment to @​z frees the IV(1) which is still left on the
stack and $_ is aliased to it. The $$p autovivifies $p to ref, which
requires allocating a new SV and the IV(1) gets chosen for the task.
Subsequently, all hell breaks loose.

I think this is another ticket we just move to the public queue and
attach to the 'stack-not-refcounted' meta-ticket.

I'll do this in a few days time unless anyone objects.

--
The Enterprise's efficient long-range scanners detect a temporal vortex
distortion in good time, allowing it to be safely avoided via a minor
course correction.
  -- Things That Never Happen in "Star Trek" #21

From @iabyn

On Mon, Feb 27, 2017 at 02​:37​:58PM +0000, Dave Mitchell wrote​:

On Sun, Feb 26, 2017 at 08​:58​:19PM -0800, Tony Cook via RT wrote​:

On Sun, 26 Feb 2017 10​:12​:45 -0800, arc@​aaroncrane.co.uk wrote​:

Reduction​:

$ ./miniperl -e 'map $p[0][0],@​z=z,@​z=z,@​z=z,@​z=z,@​z=z,@​z= ~9'
...
SUMMARY​: AddressSanitizer​: bad-free
(libclang_rt.asan_osx_dynamic.dylib+0x46939) in wrap_free
==13111==ABORTING
Abort trap​: 6

I was slightly surprised (a) that the multideref needn't look at the
assigned array to trigger this, and (b) that all the array assignments
are necessary.

My first guess is that this is ultimately stack-not-refcounted, but I
haven't looked into that.

It's pretty common for stack-not-refcounted bugs to introduce just strange behaviour, with a slight variation required to make it crash, or assert​:

$ ./miniperl -e 'map $p[0][0],@​z=z,@​z=(1..3),@​z= ~9'
miniperl​: sv.c​:6557​: Perl_sv_clear​: Assertion `((svtype)((sv)->sv_flags & 0xff)) != (svtype)0xff' failed.
Aborted

(which is a typical stack-not-refcounted assert().)

It can be reduced even further to

map $$p\, @​z=1\, @​z=2;

The second assignment to @​z frees the IV(1) which is still left on the
stack and $_ is aliased to it. The $$p autovivifies $p to ref, which
requires allocating a new SV and the IV(1) gets chosen for the task.
Subsequently, all hell breaks loose.

I think this is another ticket we just move to the public queue and
attach to the 'stack-not-refcounted' meta-ticket.

I'll do this in a few days time unless anyone objects.

Now doing it.

--
"But Sidley Park is already a picture, and a most amiable picture too.
The slopes are green and gentle. The trees are companionably grouped at
intervals that show them to advantage. The rill is a serpentine ribbon
unwound from the lake peaceably contained by meadows on which the right
amount of sheep are tastefully arranged." -- Lady Croom, "Arcadia"