SEGV (sv.c:16672:7) in S_find_uninit_var

[p5pRT]

Migrated from rt.perl.org#134275 (status was 'pending release')

Searchable as RT134275$

[p5pRT]

From imdb95@gmail.com

Hello,
I found this bug when fuzzing perl5.

**********Compilation and environment**********
root@​instance-2​:~/fuzz_perl# ./perl/perl -v

This is perl 5, version 31, subversion 2 (v5.31.2 (v5.31.1-6-g9649a81))
built for x86_64-linux

Copyright 1987-2019, Larry Wall

Perl may be copied only under the terms of either the Artistic License or
the
GNU General Public License, which may be found in the Perl 5 source kit.

Complete documentation for Perl, including FAQ lists, should be found on
this system using "man perl" or "perldoc perl". If you have access to the
Internet, point your browser at http​://www.perl.org/, the Perl Home Page.

---

root@​instance-2​:~/fuzz_perl# uname -a
Linux instance-2 4.15.0-1036-gcp #38~16.04.1-Ubuntu SMP Tue Jun 25 15​:30​:46
UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

---

root@​instance-2​:~/fuzz_perl# lsb_release -r
Release​: 16.04

---

Compilation​:
AFL_USE_ASAN=1 ./Configure -des -Dusedevel -DDEBUGGING -Dcc=afl-clang-fast
-Doptimize=-g && AFL_USE_ASAN=1 make

**********Reproduce*********
root@​instance-2​:~/fuzz_perl# ./perl/perl test.pl
Use of uninitialized value in regexp compilation at test.pl line 1.
ASAN​:DEADLYSIGNAL

==16809==ERROR​: AddressSanitizer​: SEGV on unknown address 0x00000000000e
(pc 0x000000a5b363 bp 0x000000000000 sp 0x7ffefbd990c0 T0)
==16809==The signal is caused by a READ memory access.
==16809==Hint​: address points to the zero page.
  #0 0xa5b362 in S_find_uninit_var /root/fuzz_perl/perl/sv.c​:16672​:7
  #1 0xa589c5 in S_find_uninit_var /root/fuzz_perl/perl/sv.c​:16923​:11
  #2 0x9b333e in Perl_report_uninit /root/fuzz_perl/perl/sv.c​:16956​:16
  #3 0x9acc4e in Perl_sv_2pv_flags /root/fuzz_perl/perl/sv.c​:3251​:6
  #4 0x9f5336 in Perl_sv_catsv_flags /root/fuzz_perl/perl/sv.c​:5550​:20
  #5 0x744ebd in S_concat_pat /root/fuzz_perl/perl/regcomp.c​:6822​:17
  #6 0x7276d4 in Perl_re_op_compile /root/fuzz_perl/perl/regcomp.c​:7478​:11
  #7 0xb09f34 in Perl_pp_regcomp /root/fuzz_perl/perl/pp_ctl.c​:108​:14
  #8 0x88087c in Perl_runops_debug /root/fuzz_perl/perl/dump.c​:2537​:23
  #9 0x5e95f2 in S_run_body /root/fuzz_perl/perl/perl.c
  #10 0x5e95f2 in perl_run /root/fuzz_perl/perl/perl.c​:2639
  #11 0x50a398 in main /root/fuzz_perl/perl/perlmain.c​:127​:9
  #12 0x7fbdff93282f in __libc_start_main
(/lib/x86_64-linux-gnu/libc.so.6+0x2082f)
  #13 0x4368c8 in _start (/root/fuzz_perl/perl/perl+0x4368c8)

AddressSanitizer can not provide additional info.
SUMMARY​: AddressSanitizer​: SEGV /root/fuzz_perl/perl/sv.c​:16672​:7 in
S_find_uninit_var
==16809==ABORTING

Please confirm the bug. Crash also happens with the default version v5.22.1
of perl on Ubuntu

Thanks,
Manh Nguyen

[p5pRT]

From @iabyn

On Tue, Jul 09, 2019 at 02​:15​:50AM -0700, Nguyen Duc Manh wrote​:

root@​instance-2​:~/fuzz_perl# ./perl/perl test.pl

You don't appear to have included the contents of test.pl in your report.

--
"Emacs isn't a bad OS once you get used to it.
It just lacks a decent editor."

[p5pRT]

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

[p5pRT]

From imdb95@gmail.com

Sorry!
Here it is​: '' =~ /@​{$^W=g^_}$_{a}${*0=*_=0}$00/;

On Tue, Jul 9, 2019 at 5​:10 PM Dave Mitchell via RT <
perl5-security-report-followup@​perl.org> wrote​:

You don't appear to have included the contents of test.pl in your report.

[p5pRT]

From @iabyn

On Tue, Jul 09, 2019 at 05​:14​:27PM +0700, Peter Nguyen wrote​:

Sorry!
Here it is​: '' =~ /@​{$^W=g^_}$_{a}${*0=*_=0}$00/;

Fixed with the commit below. I don't consider it a security issue, because
it can only be triggered by convoluted src code, not by a convoluted
regex pattern. And the only thing it can trigger is a SEGV from dereffing
a NULL pointer.

commit 28eabf1
Author​: David Mitchell <davem@​iabyn.com>
AuthorDate​: Wed Jul 10 12​:59​:06 2019 +0100
Commit​: David Mitchell <davem@​iabyn.com>
CommitDate​: Wed Jul 10 12​:59​:06 2019 +0100

  avoid SEGV with uninit warning with multideref
 
  RT #134275
 
  When the 'uninitialized warning' code in S_find_uninit_var() comes
  across an OP_MULTIDEREF node, it scans it to see if any part of that op
  (e.g. the indices or the returned value) could have been the source of
  the uninitialized value which triggered the warning. Unfortunately when
  getting an AV or HV from a GV, it wasn't checking whether gp_av/gp_hv
  contained a NULL value. If so, it would SEGV.
 
  The test code is a bit contrived; you have to "pull the rug" from under
  the GV at just the right moment with *foo = *bar, then trigger an uninit
  warning on an op whose subtree includes an OP_MULTIDEREF.

M sv.c
M t/lib/warnings/9uninit

--
No man treats a motor car as foolishly as he treats another human being.
When the car will not go, he does not attribute its annoying behaviour to
sin, he does not say, You are a wicked motorcar, and I shall not give you
any more petrol until you go. He attempts to find out what is wrong and
set it right.
  -- Bertrand Russell,
  Has Religion Made Useful Contributions to Civilization?

[p5pRT]

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