Assertion failed: Perl_sv_2iv_flags (sv.c:2435)

[p5pRT]

Migrated from rt.perl.org#126193 (status was 'resolved')

Searchable as RT126193$

[p5pRT]

From @geeknik

Fuzzing perl v5.23.4 (v5.23.3-7-ge120c24) with AFL found the following assertion failure​:

perl -e '{$0{@​{[()[[]=~m[@​]]*0]}}}{}'

perl​: sv.c​:2435​: Perl_sv_2iv_flags​: Assertion `((svtype)((sv)->sv_flags & 0xff)) != SVt_PVAV && ((svtype)((sv)->sv_flags & 0xff)) != SVt_PVHV && ((svtype)((sv)->sv_flags & 0xff)) != SVt_PVFM' failed.
Aborted

Program received signal SIGABRT, Aborted.
0x00007ffff6d90165 in *__GI_raise (sig=<optimized out>)
  at ../nptl/sysdeps/unix/sysv/linux/raise.c​:64
64 ../nptl/sysdeps/unix/sysv/linux/raise.c​: No such file or directory.
(gdb) bt
#0 0x00007ffff6d90165 in *__GI_raise (sig=<optimized out>)
  at ../nptl/sysdeps/unix/sysv/linux/raise.c​:64
#1 0x00007ffff6d933e0 in *__GI_abort () at abort.c​:92
#2 0x00007ffff6d89311 in *__GI___assert_fail (
  assertion=0xf7a7f0 "((svtype)((sv)->sv_flags & 0xff)) != SVt_PVAV && ((svtype)((sv)->sv_flags & 0xff)) != SVt_PVHV && ((svtype)((sv)->sv_flags & 0xff)) != SVt_PVFM", file=<optimized out>,
  line=2435, function=0xf8f8b0 "Perl_sv_2iv_flags") at assert.c​:81
#3 0x0000000000a1d511 in Perl_sv_2iv_flags () at sv.c​:2434
#4 0x0000000000ae6886 in Perl_pp_lslice () at pp.c​:5112
#5 0x00000000007e523f in Perl_runops_debug () at dump.c​:2224
#6 0x0000000000545b99 in perl_run () at perl.c​:2456
#7 0x000000000042c988 in main () at perlmain.c​:116

Script doesn't appear to affect v5.21.7 (v5.21.6-602-ge9d2bd8) in any way.

[p5pRT]

From @dcollinsn

Greetings Porters,

I have compiled bleadperl with the afl-gcc compiler using​:

./Configure -Dusedevel -Dprefix='/usr/local/perl-afl' -Dcc='ccache afl-gcc' -Duselongdouble -Duse64bitall -Doptimize=-g -Uversiononly -Uman1dir -Uman3dir -des
AFL_HARDEN=1 make && make test

And then fuzzed the resulting binary using​:

AFL_NO_VAR_CHECK=1 afl-fuzz -i in -o out bin/perl @​@​

After reducing testcases using `afl-tmin` and performing additional minimization by hand, I have located the following testcase that triggers a segmentation fault in the perl interpreter. The testcase is the file​:

($0[(((0/[(())])[()]))])

On standard perls, this results in a SIGSEGV. In debugging perls, this results in the following output​:

perl​: sv.c​:2435​: Perl_sv_2iv_flags​: Assertion `((svtype)((sv)->sv_flags & 0xff)) != SVt_PVAV && ((svtype)((sv)->sv_flags & 0xff)) != SVt_PVHV && ((svtype)((sv)->sv_flags & 0xff)) != SVt_PVFM' failed.
Aborted

**GDB**

(gdb) run
Starting program​: /home/dcollins/perl/perl -e \(\$0\[\(\(\(0/\[\(\(\)\)\]\)\[\(\)\]\)\)\]\)
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
0x0000000000aeb260 in Perl_grok_number_flags (pv=0x0, len=18446744073709551615, valuep=0x7fffffffe370, flags=0) at numeric.c​:857
857 while (s < send && isSPACE(*s))
(gdb) bt
#0 0x0000000000aeb260 in Perl_grok_number_flags (pv=0x0, len=18446744073709551615, valuep=0x7fffffffe370, flags=0) at numeric.c​:857
#1 0x00000000007fc884 in Perl_sv_2iv_flags (sv=0xe7a8e8, flags=-1, flags@​entry=2) at sv.c​:2467
#2 0x000000000087dbfa in Perl_pp_lslice () at pp.c​:5113
#3 0x000000000076c45b in Perl_runops_standard () at run.c​:41
#4 0x00000000004ee9af in S_run_body (oldscope=1) at perl.c​:2456
#5 perl_run (my_perl=<optimized out>) at perl.c​:2379
#6 0x00000000004261c8 in main (argc=3, argv=0x7fffffffe648, env=0x7fffffffe668) at perlmain.c​:116
(gdb) info locals
s = 0x0
send = 0xffffffffffffffff <error​: Cannot access memory at address 0xffffffffffffffff>
d = 0xe6b1f8 "\001"
numtype = 0

**VALGRIND**

==6349== Memcheck, a memory error detector
==6349== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==6349== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
==6349== Command​: /home/dcollins/perl/perl -e ($0[(((0/[(())])[()]))])
==6349==
==6349== Invalid read of size 1
==6349== at 0xAEB260​: Perl_grok_number_flags (numeric.c​:857)
==6349== by 0x7FC883​: Perl_sv_2iv_flags (sv.c​:2467)
==6349== by 0x87DBF9​: Perl_pp_lslice (pp.c​:5113)
==6349== by 0x76C45A​: Perl_runops_standard (run.c​:41)
==6349== by 0x4EE9AE​: S_run_body (perl.c​:2456)
==6349== by 0x4EE9AE​: perl_run (perl.c​:2379)
==6349== by 0x4261C7​: main (perlmain.c​:116)
==6349== Address 0x0 is not stack'd, malloc'd or (recently) free'd
==6349==
==6349==
==6349== Process terminating with default action of signal 11 (SIGSEGV)
==6349== Access not within mapped region at address 0x0
==6349== at 0xAEB260​: Perl_grok_number_flags (numeric.c​:857)
==6349== by 0x7FC883​: Perl_sv_2iv_flags (sv.c​:2467)
==6349== by 0x87DBF9​: Perl_pp_lslice (pp.c​:5113)
==6349== by 0x76C45A​: Perl_runops_standard (run.c​:41)
==6349== by 0x4EE9AE​: S_run_body (perl.c​:2456)
==6349== by 0x4EE9AE​: perl_run (perl.c​:2379)
==6349== by 0x4261C7​: main (perlmain.c​:116)
==6349== If you believe this happened as a result of a stack
==6349== overflow in your program's main thread (unlikely but
==6349== possible), you can try to increase the size of the
==6349== main thread stack using the --main-stacksize= flag.
==6349== The main thread stack size used in this run was 8388608.
==6349==
==6349== HEAP SUMMARY​:
==6349== in use at exit​: 113,814 bytes in 537 blocks
==6349== total heap usage​: 634 allocs, 97 frees, 128,928 bytes allocated
==6349==
==6349== LEAK SUMMARY​:
==6349== definitely lost​: 176 bytes in 1 blocks
==6349== indirectly lost​: 1,993 bytes in 20 blocks
==6349== possibly lost​: 0 bytes in 0 blocks
==6349== still reachable​: 111,645 bytes in 516 blocks
==6349== suppressed​: 0 bytes in 0 blocks
==6349== Rerun with --leak-check=full to see details of leaked memory
==6349==
==6349== For counts of detected and suppressed errors, rerun with​: -v
==6349== ERROR SUMMARY​: 1 errors from 1 contexts (suppressed​: 0 from 0)
Segmentation fault

**PERL -V**

Summary of my perl5 (revision 5 version 23 subversion 4) configuration​:
  Commit id​: 94757bf
  Platform​:
  osname=linux, osvers=3.16.0-4-amd64, archname=x86_64-linux-ld
  uname='linux nightshade64 3.16.0-4-amd64 #1 smp debian 3.16.7-ckt11-1+deb8u4 (2015-09-19) x86_64 gnulinux '
  config_args='-Dusedevel -Dprefix=/usr/local/perl-afl -Dcc=ccache afl-gcc -Duselongdouble -Duse64bitall -Doptimize=-g -Uversiononly -Uman1dir -Uman3dir -DDEBUGGING -DPERL_POISON -des'
  hint=recommended, useposix=true, d_sigaction=define
  useithreads=undef, usemultiplicity=undef
  use64bitint=define, use64bitall=define, uselongdouble=define
  usemymalloc=n, bincompat5005=undef
  Compiler​:
  cc='ccache afl-gcc', ccflags ='-fwrapv -DDEBUGGING -fno-strict-aliasing -pipe -fstack-protector-strong -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64',
  optimize='-g',
  cppflags='-fwrapv -DDEBUGGING -fno-strict-aliasing -pipe -fstack-protector-strong -I/usr/local/include'
  ccversion='', gccversion='4.9.2', gccosandvers=''
  intsize=4, longsize=8, ptrsize=8, doublesize=8, byteorder=12345678, doublekind=3
  d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16, longdblkind=3
  ivtype='long', ivsize=8, nvtype='long double', nvsize=16, Off_t='off_t', lseeksize=8
  alignbytes=16, prototype=define
  Linker and Libraries​:
  ld='ccache afl-gcc', ldflags =' -fstack-protector-strong -L/usr/local/lib'
  libpth=/usr/local/lib /usr/lib/gcc/x86_64-linux-gnu/4.9/include-fixed /usr/include/x86_64-linux-gnu /usr/lib /lib/x86_64-linux-gnu /lib/../lib /usr/lib/x86_64-linux-gnu /usr/lib/../lib /lib
  libs=-lpthread -lnsl -ldl -lm -lcrypt -lutil -lc
  perllibs=-lpthread -lnsl -ldl -lm -lcrypt -lutil -lc
  libc=libc-2.19.so, so=so, useshrplib=false, libperl=libperl.a
  gnulibc_version='2.19'
  Dynamic Linking​:
  dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E'
  cccdlflags='-fPIC', lddlflags='-shared -g -L/usr/local/lib -fstack-protector-strong'

Characteristics of this binary (from libperl)​:
  Compile-time options​: HAS_TIMES PERLIO_LAYERS PERL_COPY_ON_WRITE
  PERL_DONT_CREATE_GVSV
  PERL_HASH_FUNC_ONE_AT_A_TIME_HARD PERL_MALLOC_WRAP
  PERL_PRESERVE_IVUV PERL_USE_DEVEL USE_64_BIT_ALL
  USE_64_BIT_INT USE_LARGE_FILES USE_LOCALE
  USE_LOCALE_COLLATE USE_LOCALE_CTYPE
  USE_LOCALE_NUMERIC USE_LOCALE_TIME USE_LONG_DOUBLE
  USE_PERLIO USE_PERL_ATOF
  Built under linux
  Compiled at Oct 2 2015 22​:37​:40
  @​INC​:
  /usr/local/perl-afl/lib/site_perl/5.23.4/x86_64-linux-ld
  /usr/local/perl-afl/lib/site_perl/5.23.4
  /usr/local/perl-afl/lib/5.23.4/x86_64-linux-ld
  /usr/local/perl-afl/lib/5.23.4
  .

[p5pRT]

From victor@drawall.cc

I performed some additional reduction by hand. The following causes
the same error (SIGSEGV with identical backtrace)​:

$0[()[()]]

[p5pRT]

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

[p5pRT]

From @geeknik

On Mon Oct 12 04​:37​:26 2015, victor@​drawall.cc wrote​:

I performed some additional reduction by hand. The following causes
the same error (SIGSEGV with identical backtrace)​:

$0[()[()]]

Probably a dupe of https://rt-archive.perl.org/perl5/Ticket/Display.html?id=126193.

[p5pRT]

From [Unknown Contact. See original ticket]

On Mon Oct 12 04​:37​:26 2015, victor@​drawall.cc wrote​:

I performed some additional reduction by hand. The following causes
the same error (SIGSEGV with identical backtrace)​:

$0[()[()]]

Probably a dupe of https://rt-archive.perl.org/perl5/Ticket/Display.html?id=126193.

[p5pRT]

From @tonycoz

On Mon Oct 12 11​:52​:59 2015, brian.carpenter@​gmail.com wrote​:

On Mon Oct 12 04​:37​:26 2015, victor@​drawall.cc wrote​:

I performed some additional reduction by hand. The following causes
the same error (SIGSEGV with identical backtrace)​:

$0[()[()]]

Probably a dupe of https://rt-archive.perl.org/perl5/Ticket/Display.html?id=126193.

Looks like it to me, so I've merged them.

The attached patch fixes the problem for me.

Tony

[p5pRT]

From @tonycoz

0001-perl-126193-don-t-use-a-trash-SV-if-no-indexes-are-p.patch

From c902887933f2025fd547357674c2699a1a95c96f Mon Sep 17 00:00:00 2001
From: Tony Cook <tony@develop-help.com>
Date: Wed, 11 Nov 2015 15:57:09 +1100
Subject: [perl #126193] don't use a trash SV if no indexes are provided to
 pp_lslice

---
 pp.c        | 23 ++++++++++++++---------
 t/op/list.t |  5 ++++-
 2 files changed, 18 insertions(+), 10 deletions(-)

diff --git a/pp.c b/pp.c
index 35a5f26..7301d8b 100644
--- a/pp.c
+++ b/pp.c
@@ -5268,15 +5268,20 @@ PP(pp_lslice)
     SV **lelem;
 
     if (GIMME_V != G_ARRAY) {
-	I32 ix = SvIV(*lastlelem);
-	if (ix < 0)
-	    ix += max;
-	if (ix < 0 || ix >= max)
-	    *firstlelem = &PL_sv_undef;
-	else
-	    *firstlelem = firstrelem[ix];
-	SP = firstlelem;
-	RETURN;
+        if (lastlelem < firstlelem) {
+            *firstlelem = &PL_sv_undef;
+        }
+        else {
+            I32 ix = SvIV(*lastlelem);
+            if (ix < 0)
+                ix += max;
+            if (ix < 0 || ix >= max)
+                *firstlelem = &PL_sv_undef;
+            else
+                *firstlelem = firstrelem[ix];
+        }
+        SP = firstlelem;
+        RETURN;
     }
 
     if (max == 0) {
diff --git a/t/op/list.t b/t/op/list.t
index c7056d0..9fe00a4 100644
--- a/t/op/list.t
+++ b/t/op/list.t
@@ -6,7 +6,7 @@ BEGIN {
     require "./test.pl";
 }
 
-plan( tests => 69 );
+plan( tests => 70 );
 
 @foo = (1, 2, 3, 4);
 cmp_ok($foo[0], '==', 1, 'first elem');
@@ -217,3 +217,6 @@ sub empty {}
 tie $t, "";
 () = (empty(), ($t)x10); # empty() since sub calls usually result in copies
 is(tied($t)->{fetched}, undef, 'assignment to empty list makes no copies');
+
+# this was passing a trash SV at the top of the stack to SvIV()
+ok(($0[()[()]],1), "[perl #126193] list slice with zero indexes");
-- 
2.1.4

[p5pRT]

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

[p5pRT]

From @tonycoz

On Tue Nov 10 20​:59​:32 2015, tonyc wrote​:

On Mon Oct 12 11​:52​:59 2015, brian.carpenter@​gmail.com wrote​:

On Mon Oct 12 04​:37​:26 2015, victor@​drawall.cc wrote​:

I performed some additional reduction by hand. The following causes
the same error (SIGSEGV with identical backtrace)​:

$0[()[()]]

Probably a dupe of https://rt-archive.perl.org/perl5/Ticket/Display.html?id=126193.

Looks like it to me, so I've merged them.

The attached patch fixes the problem for me.

Applied as 9e59c36.

Tony

[p5pRT]

@tonycoz - Status changed from 'open' to 'pending release'

[p5pRT]

From @khwilliamson

Thank you for submitting this report. You have helped make Perl better.
 
With the release of Perl 5.24.0 on May 9, 2016, this and 149 other issues have been resolved.

Perl 5.24.0 may be downloaded via https://metacpan.org/release/RJBS/perl-5.24.0

[p5pRT]

@khwilliamson - Status changed from 'pending release' to 'resolved'