Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

segfault in S_regnode_guts #16011

Closed
p5pRT opened this issue Jun 10, 2017 · 25 comments
Closed

segfault in S_regnode_guts #16011

p5pRT opened this issue Jun 10, 2017 · 25 comments

Comments

@p5pRT
Copy link

p5pRT commented Jun 10, 2017

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

Searchable as RT131551$

@p5pRT
Copy link
Author

p5pRT commented Jun 10, 2017

From @geeknik

Triggered with Perl v5.27.0-97-gd555ed0, compiled with afl-clang-fast on
Debian 8 x64.

./perl -Dt test203.pl

eeeeeeeeeeeeueeeeeeeeeeeect l$time )= *hum?▒
(test203.pl​:1) gv(main​::_Udo)
(test203.pl​:1) rv2hv
(test203.pl​:1) hslice
(test203.pl​:1) const(PV("4} "\0))
(test203.pl​:1) regcomp
Segmentation fault

Program received signal SIGSEGV, Segmentation fault.
0x0000000000798588 in S_regnode_guts (pRExC_state=0x7fffffffdf00,
  op=238 '\356', extra_size=1, name=0x0) at regcomp.c​:18485
18485 PERL_ARGS_ASSERT_REGNODE_GUTS;
(gdb) bt
#0 0x0000000000798588 in S_regnode_guts (pRExC_state=0x7fffffffdf00,
  op=238 '\356', extra_size=1, name=0x0) at regcomp.c​:18485
#1 0x0000000041b58ab3 in ?? ()
#2 0x000000000121ecce in ?? ()
#3 0x0000000000798430 in ?? () at regcomp.c​:8730
#4 0x0000000000000000 in ?? ()

@p5pRT
Copy link
Author

p5pRT commented Jun 10, 2017

From @geeknik

test203.pl.gz

@p5pRT
Copy link
Author

p5pRT commented Jun 10, 2017

From @khwilliamson

On 06/09/2017 10​:16 PM, Brian Carpenter (via RT) wrote​:

# New Ticket Created by Brian Carpenter
# Please include the string​: [perl #131551]
# in the subject line of all future correspondence about this issue.
# <URL​: https://rt-archive.perl.org/perl5/Ticket/Display.html?id=131551 >

Triggered with Perl v5.27.0-97-gd555ed0, compiled with afl-clang-fast on
Debian 8 x64.

./perl -Dt test203.pl

eeeeeeeeeeeeueeeeeeeeeeeect l$time )= *hum?▒
(test203.pl​:1) gv(main​::_Udo)
(test203.pl​:1) rv2hv
(test203.pl​:1) hslice
(test203.pl​:1) const(PV("4} "\0))
(test203.pl​:1) regcomp
Segmentation fault

Program received signal SIGSEGV, Segmentation fault.
0x0000000000798588 in S_regnode_guts (pRExC_state=0x7fffffffdf00,
op=238 '\356', extra_size=1, name=0x0) at regcomp.c​:18485
18485 PERL_ARGS_ASSERT_REGNODE_GUTS;
(gdb) bt
#0 0x0000000000798588 in S_regnode_guts (pRExC_state=0x7fffffffdf00,
op=238 '\356', extra_size=1, name=0x0) at regcomp.c​:18485
#1 0x0000000041b58ab3 in ?? ()
#2 0x000000000121ecce in ?? ()
#3 0x0000000000798430 in ?? () at regcomp.c​:8730
#4 0x0000000000000000 in ?? ()

Attached is the valgrind output

@p5pRT
Copy link
Author

p5pRT commented Jun 10, 2017

From @khwilliamson

131551.log

@p5pRT
Copy link
Author

p5pRT commented Jun 10, 2017

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

@p5pRT
Copy link
Author

p5pRT commented Jun 12, 2017

From @tonycoz

On Sat, 10 Jun 2017 08​:04​:50 -0700, public@​khwilliamson.com wrote​:

On 06/09/2017 10​:16 PM, Brian Carpenter (via RT) wrote​:

# New Ticket Created by Brian Carpenter
# Please include the string​: [perl #131551]
# in the subject line of all future correspondence about this issue.
# <URL​: https://rt-archive.perl.org/perl5/Ticket/Display.html?id=131551 >

Triggered with Perl v5.27.0-97-gd555ed0, compiled with afl-clang-fast on
Debian 8 x64.

./perl -Dt test203.pl

eeeeeeeeeeeeueeeeeeeeeeeect l$time )= *hum?▒
(test203.pl​:1) gv(main​::_Udo)
(test203.pl​:1) rv2hv
(test203.pl​:1) hslice
(test203.pl​:1) const(PV("4} "\0))
(test203.pl​:1) regcomp
Segmentation fault

Program received signal SIGSEGV, Segmentation fault.
0x0000000000798588 in S_regnode_guts (pRExC_state=0x7fffffffdf00,
op=238 '\356', extra_size=1, name=0x0) at regcomp.c​:18485
18485 PERL_ARGS_ASSERT_REGNODE_GUTS;
(gdb) bt
#0 0x0000000000798588 in S_regnode_guts (pRExC_state=0x7fffffffdf00,
op=238 '\356', extra_size=1, name=0x0) at regcomp.c​:18485
#1 0x0000000041b58ab3 in ?? ()
#2 0x000000000121ecce in ?? ()
#3 0x0000000000798430 in ?? () at regcomp.c​:8730
#4 0x0000000000000000 in ?? ()

Attached is the valgrind output

Your case looks like a simple stack overflow from recursion failure​:

$ gdb -q --args ./perl -e '$x = "(" x 4096; qr/$x/'
Reading symbols from ./perl...done.
(gdb) r
Starting program​: /home/tony/dev/perl/git/perl/perl -e \$x\ =\ \"\(\"\ x\ 4096\;\ qr/\$x/
[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.
0x000000000052b637 in S_regatom (
  pRExC_state=<error reading variable​: Cannot access memory at address 0x7fffff7fedf8>,
  flagp=<error reading variable​: Cannot access memory at address 0x7fffff7fedf0>,
  depth=<error reading variable​: Cannot access memory at address 0x7fffff7fedec>) at regcomp.c​:12533
12533 {
(bt shows 14561 stack frames)

It's hard to tell if that's the same issue Brian is seeing.

Tony

@p5pRT
Copy link
Author

p5pRT commented Jun 12, 2017

From @demerphq

On 12 June 2017 at 03​:51, Tony Cook via RT <perlbug-followup@​perl.org> wrote​:

On Sat, 10 Jun 2017 08​:04​:50 -0700, public@​khwilliamson.com wrote​:

On 06/09/2017 10​:16 PM, Brian Carpenter (via RT) wrote​:

# New Ticket Created by Brian Carpenter
# Please include the string​: [perl #131551]
# in the subject line of all future correspondence about this issue.
# <URL​: https://rt-archive.perl.org/perl5/Ticket/Display.html?id=131551 >

Triggered with Perl v5.27.0-97-gd555ed0, compiled with afl-clang-fast on
Debian 8 x64.

./perl -Dt test203.pl

eeeeeeeeeeeeueeeeeeeeeeeect l$time )= *hum?▒
(test203.pl​:1) gv(main​::_Udo)
(test203.pl​:1) rv2hv
(test203.pl​:1) hslice
(test203.pl​:1) const(PV("4} "\0))
(test203.pl​:1) regcomp
Segmentation fault

Program received signal SIGSEGV, Segmentation fault.
0x0000000000798588 in S_regnode_guts (pRExC_state=0x7fffffffdf00,
op=238 '\356', extra_size=1, name=0x0) at regcomp.c​:18485
18485 PERL_ARGS_ASSERT_REGNODE_GUTS;
(gdb) bt
#0 0x0000000000798588 in S_regnode_guts (pRExC_state=0x7fffffffdf00,
op=238 '\356', extra_size=1, name=0x0) at regcomp.c​:18485
#1 0x0000000041b58ab3 in ?? ()
#2 0x000000000121ecce in ?? ()
#3 0x0000000000798430 in ?? () at regcomp.c​:8730
#4 0x0000000000000000 in ?? ()

Attached is the valgrind output

Your case looks like a simple stack overflow from recursion failure​:

$ gdb -q --args ./perl -e '$x = "(" x 4096; qr/$x/'
Reading symbols from ./perl...done.
(gdb) r
Starting program​: /home/tony/dev/perl/git/perl/perl -e \$x\ =\ \"\(\"\ x\ 4096\;\ qr/\$x/
[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.
0x000000000052b637 in S_regatom (
pRExC_state=<error reading variable​: Cannot access memory at address 0x7fffff7fedf8>,
flagp=<error reading variable​: Cannot access memory at address 0x7fffff7fedf0>,
depth=<error reading variable​: Cannot access memory at address 0x7fffff7fedec>) at regcomp.c​:12533
12533 {
(bt shows 14561 stack frames)

It's hard to tell if that's the same issue Brian is seeing.

Oooh. Nice catch. Regex execution does not use recursion. Regex
compilation does. Not sure what we can do about that off hand.

Yves

--
perl -Mre=debug -e "/just|another|perl|hacker/"

@p5pRT
Copy link
Author

p5pRT commented Jun 13, 2017

From @tonycoz

On Fri, 09 Jun 2017 21​:16​:13 -0700, brian.carpenter@​gmail.com wrote​:

Triggered with Perl v5.27.0-97-gd555ed0, compiled with afl-clang-fast on
Debian 8 x64.

./perl -Dt test203.pl

eeeeeeeeeeeeueeeeeeeeeeeect l$time )= *hum?▒
(test203.pl​:1) gv(main​::_Udo)
(test203.pl​:1) rv2hv
(test203.pl​:1) hslice
(test203.pl​:1) const(PV("4} "\0))
(test203.pl​:1) regcomp
Segmentation fault

Program received signal SIGSEGV, Segmentation fault.
0x0000000000798588 in S_regnode_guts (pRExC_state=0x7fffffffdf00,
op=238 '\356', extra_size=1, name=0x0) at regcomp.c​:18485
18485 PERL_ARGS_ASSERT_REGNODE_GUTS;
(gdb) bt
#0 0x0000000000798588 in S_regnode_guts (pRExC_state=0x7fffffffdf00,
op=238 '\356', extra_size=1, name=0x0) at regcomp.c​:18485
#1 0x0000000041b58ab3 in ?? ()
#2 0x000000000121ecce in ?? ()
#3 0x0000000000798430 in ?? () at regcomp.c​:8730
#4 0x0000000000000000 in ?? ()

Brian, I've only managed to crash this with very deep recursion.

Could you please try to reproduce this with more debugging information?

That might give us a more useful backtrace.

Tony

@p5pRT
Copy link
Author

p5pRT commented Jun 13, 2017

From @geeknik

What more can I do? I compiled it like so​:

./Configure -des -Dusedevel -DDEBUGGING -Dcc=afl-clang-fast -Doptimize=-O2\
-g && AFL_USE_ASAN=1 make

Here is the full debug output from my end​:

./perl -Dt test203.pl
$* is no longer supported. Its use will be fatal in Perl 5.30 at test203.pl
line 2.

EXECUTING...

(test203.pl​:0) enter
(test203.pl​:0) nextstate
(test203.pl​:1) pushmark
(test203.pl​:1) gv(main​::DATA)
(test203.pl​:1) readline
(test203.pl​:1) mapstart
(test203.pl​:1) enter
(test203.pl​:1) nextstate
(test203.pl​:1) const(PV("9\0338"\0))
(test203.pl​:1) pushmark
(test203.pl​:1) const(PV("[\\\\LC4~r\203\0330\n .\25 \2 ,"\0))
(test203.pl​:1) gvsv(main​::*)
(test203.pl​:1) const(PV("\0\0\0 "\0))
(test203.pl​:1) gvsv(main​::_)
(test203.pl​:1) const(PV("\272l]=>0ap{"\0))
(test203.pl​:1) pushmark
(test203.pl​:1) subst
(test203.pl​:1) pushmark
(test203.pl​:1) gvsv(main​::_)
(test203.pl​:1) print
while % % ^ * % % %-% [] %?%
((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((J(((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((▒((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((?((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((()(((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((eeeeeeeeeeeeueeeeeeeeeeeect
  l$time )= *hum?▒
(test203.pl​:1) gv(main​::_Udo)
(test203.pl​:1) rv2hv
(test203.pl​:1) hslice
(test203.pl​:1) const(PV("4} "\0))
(test203.pl​:1) regcomp
Segmentation fault

On Mon, Jun 12, 2017 at 7​:17 PM, Tony Cook via RT <perlbug-followup@​perl.org

wrote​:

On Fri, 09 Jun 2017 21​:16​:13 -0700, brian.carpenter@​gmail.com wrote​:

Triggered with Perl v5.27.0-97-gd555ed0, compiled with afl-clang-fast on
Debian 8 x64.

./perl -Dt test203.pl

eeeeeeeeeeeeueeeeeeeeeeeect l$time )= *hum?▒
(test203.pl​:1) gv(main​::_Udo)
(test203.pl​:1) rv2hv
(test203.pl​:1) hslice
(test203.pl​:1) const(PV("4} "\0))
(test203.pl​:1) regcomp
Segmentation fault

Program received signal SIGSEGV, Segmentation fault.
0x0000000000798588 in S_regnode_guts (pRExC_state=0x7fffffffdf00,
op=238 '\356', extra_size=1, name=0x0) at regcomp.c​:18485
18485 PERL_ARGS_ASSERT_REGNODE_GUTS;
(gdb) bt
#0 0x0000000000798588 in S_regnode_guts (pRExC_state=0x7fffffffdf00,
op=238 '\356', extra_size=1, name=0x0) at regcomp.c​:18485
#1 0x0000000041b58ab3 in ?? ()
#2 0x000000000121ecce in ?? ()
#3 0x0000000000798430 in ?? () at regcomp.c​:8730
#4 0x0000000000000000 in ?? ()

Brian, I've only managed to crash this with very deep recursion.

Could you please try to reproduce this with more debugging information?

That might give us a more useful backtrace.

Tony

@p5pRT
Copy link
Author

p5pRT commented Jun 13, 2017

From @tonycoz

On Mon, Jun 12, 2017 at 07​:24​:25PM -0500, Brian Carpenter wrote​:

What more can I do? I compiled it like so​:

./Configure -des -Dusedevel -DDEBUGGING -Dcc=afl-clang-fast -Doptimize=-O2\
-g && AFL_USE_ASAN=1 make

Are you using the Debian 8 clang, or some other?

Which version of afl are you using?

What's the output of​: ulimit -s

What happens if you increase the stack size​:

  ulimit -S -s 32768

If I expand the stack size I get a compilation error from failing to
compile the regex​:

Unknown switch condition (?(...)) in regex; marked by <-- HERE in m/[\\LC4~r�
while % % ^ * % % %-% [] %?% ((((((((( - goes on for many lines

Tony

@p5pRT
Copy link
Author

p5pRT commented Jun 13, 2017

From @geeknik

AFL 2.41b
Debian clang version 3.5.0-10
ulimit -s​: 8192
sigsegv doesn't happen with ulimit -S -s 32768
VM has 512MB of RAM and 2GB swap.

On Mon, Jun 12, 2017 at 8​:21 PM, Tony Cook via RT <perlbug-followup@​perl.org

wrote​:

On Mon, Jun 12, 2017 at 07​:24​:25PM -0500, Brian Carpenter wrote​:

What more can I do? I compiled it like so​:

./Configure -des -Dusedevel -DDEBUGGING -Dcc=afl-clang-fast
-Doptimize=-O2\
-g && AFL_USE_ASAN=1 make

Are you using the Debian 8 clang, or some other?

Which version of afl are you using?

What's the output of​: ulimit -s

What happens if you increase the stack size​:

ulimit -S -s 32768

If I expand the stack size I get a compilation error from failing to
compile the regex​:

Unknown switch condition (?(...)) in regex; marked by <-- HERE in
m/[\\LC4~r�
while % % ^ * % % %-% [] %?% ((((((((( - goes on for many lines

Tony

@p5pRT
Copy link
Author

p5pRT commented Jun 14, 2017

From @demerphq

On 12 June 2017 at 18​:07, demerphq <demerphq@​gmail.com> wrote​:

On 12 June 2017 at 03​:51, Tony Cook via RT <perlbug-followup@​perl.org> wrote​:

On Sat, 10 Jun 2017 08​:04​:50 -0700, public@​khwilliamson.com wrote​:

On 06/09/2017 10​:16 PM, Brian Carpenter (via RT) wrote​:

# New Ticket Created by Brian Carpenter
# Please include the string​: [perl #131551]
# in the subject line of all future correspondence about this issue.
# <URL​: https://rt-archive.perl.org/perl5/Ticket/Display.html?id=131551 >

Triggered with Perl v5.27.0-97-gd555ed0, compiled with afl-clang-fast on
Debian 8 x64.

./perl -Dt test203.pl

eeeeeeeeeeeeueeeeeeeeeeeect l$time )= *hum?▒
(test203.pl​:1) gv(main​::_Udo)
(test203.pl​:1) rv2hv
(test203.pl​:1) hslice
(test203.pl​:1) const(PV("4} "\0))
(test203.pl​:1) regcomp
Segmentation fault

Program received signal SIGSEGV, Segmentation fault.
0x0000000000798588 in S_regnode_guts (pRExC_state=0x7fffffffdf00,
op=238 '\356', extra_size=1, name=0x0) at regcomp.c​:18485
18485 PERL_ARGS_ASSERT_REGNODE_GUTS;
(gdb) bt
#0 0x0000000000798588 in S_regnode_guts (pRExC_state=0x7fffffffdf00,
op=238 '\356', extra_size=1, name=0x0) at regcomp.c​:18485
#1 0x0000000041b58ab3 in ?? ()
#2 0x000000000121ecce in ?? ()
#3 0x0000000000798430 in ?? () at regcomp.c​:8730
#4 0x0000000000000000 in ?? ()

Attached is the valgrind output

Your case looks like a simple stack overflow from recursion failure​:

$ gdb -q --args ./perl -e '$x = "(" x 4096; qr/$x/'
Reading symbols from ./perl...done.
(gdb) r
Starting program​: /home/tony/dev/perl/git/perl/perl -e \$x\ =\ \"\(\"\ x\ 4096\;\ qr/\$x/
[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.
0x000000000052b637 in S_regatom (
pRExC_state=<error reading variable​: Cannot access memory at address 0x7fffff7fedf8>,
flagp=<error reading variable​: Cannot access memory at address 0x7fffff7fedf0>,
depth=<error reading variable​: Cannot access memory at address 0x7fffff7fedec>) at regcomp.c​:12533
12533 {
(bt shows 14561 stack frames)

It's hard to tell if that's the same issue Brian is seeing.

Oooh. Nice catch. Regex execution does not use recursion. Regex
compilation does. Not sure what we can do about that off hand.

And looking a little closer I remember I added depth counts to all
these subs some years back, which means that adding a depth check is
trivial.

The only question is what should the maximum depth be, and should it
be set at compile time or at run time? If it is compile time and the
value is too large then people will still see segfaults, on the other
hand, if we allow people to set it at run time (through a magic var
somewhere, maybe ${^MAX_REGEX_PAREN_NESTING}) then they can adjust to
taste given their context.

I have to admit I lean towards setting it to a number like 1000, where
it is unlikely to break many programs but is also unlikely to blow out
anybodies stack. (Note we add four stack frames for each '(' we
encounter.)

Here is a simple patch​:

$ git diff

Inline Patch
diff --git a/regcomp.c b/regcomp.c
index 8921eed..e1d088c 100644
--- a/regcomp.c
+++ b/regcomp.c
@@ -10592,6 +10592,9 @@ S_reg(pTHX_ RExC_state_t *pRExC_state, I32
paren, I32 *flagp,U32 depth)   PERL\_ARGS\_ASSERT\_REG;   DEBUG\_PARSE\("reg "\);

+ if (depth > 4000) /* we increase depth by 4 for each open paren,
so set a limit of 1000 */
+ vFAIL("Too many nested open parens");
+
  *flagp = 0; /* Tentatively. */

  /* Having this true makes it feasible to have a lot fewer tests for the

--
perl -Mre=debug -e "/just|another|perl|hacker/"

@p5pRT
Copy link
Author

p5pRT commented Jun 16, 2017

From @tonycoz

On Tue, 13 Jun 2017 17​:14​:43 -0700, demerphq wrote​:

And looking a little closer I remember I added depth counts to all
these subs some years back, which means that adding a depth check is
trivial.

The only question is what should the maximum depth be, and should it
be set at compile time or at run time? If it is compile time and the
value is too large then people will still see segfaults, on the other
hand, if we allow people to set it at run time (through a magic var
somewhere, maybe ${^MAX_REGEX_PAREN_NESTING}) then they can adjust to
taste given their context.

I have to admit I lean towards setting it to a number like 1000, where
it is unlikely to break many programs but is also unlikely to blow out
anybodies stack. (Note we add four stack frames for each '(' we
encounter.)

1000 seems like a reasonable default limit.

Making it runtime adjustable would be good if it isn't too much effort, so
if someone explicitly sets a large stack (as with ulimit -s) they can have
more depth.

Tony

@p5pRT
Copy link
Author

p5pRT commented Feb 19, 2018

From @geeknik

perl v5.27.8-321-ge720636704 compiled with clang 7 trunk and
-fsanitize=address.

./perl -e 'm;(((((((((((((((((((((((((((((([' triggers a stack overflow
when ulimit -s = 8243 or less. If ulimit -s = 8244, we get Unmatched [ in
regex; marked by <-- HERE in m/(((((((((((((((((((((((((((((([ <-- HERE /
at test000.pl line 1.

AddressSanitizer​:DEADLYSIGNAL

==16663==ERROR​: AddressSanitizer​: stack-overflow on address 0x7ffdcd7a1f00
(pc 0x000001947519 bp 0x7ffdcd7bbcf0 sp 0x7ffdcd7a1f00 T0)
  #0 0x1947518 in S_regclass /root/perl/regcomp.c​:16224
  #1 0x189f764 in S_regatom /root/perl/regcomp.c​:12870​:15
  #2 0x186358b in S_regpiece /root/perl/regcomp.c​:11953​:11
  #3 0x17ac810 in S_regbranch /root/perl/regcomp.c​:11878​:18
  #4 0x1503f24 in S_reg /root/perl/regcomp.c​:11604​:10
  #5 0x18a66ca in S_regatom /root/perl/regcomp.c​:12894​:15
  #6 0x186358b in S_regpiece /root/perl/regcomp.c​:11953​:11
  #7 0x17ac810 in S_regbranch /root/perl/regcomp.c​:11878​:18
  #8 0x1503f24 in S_reg /root/perl/regcomp.c​:11604​:10
  #9 0x18a66ca in S_regatom /root/perl/regcomp.c​:12894​:15
  #10 0x186358b in S_regpiece /root/perl/regcomp.c​:11953​:11
*SNIP*
  #120 0x1503f24 in S_reg /root/perl/regcomp.c​:11604​:10
  #121 0x18a66ca in S_regatom /root/perl/regcomp.c​:12894​:15
  #122 0x186358b in S_regpiece /root/perl/regcomp.c​:11953​:11
  #123 0x17ac810 in S_regbranch /root/perl/regcomp.c​:11878​:18
  #124 0x1503f24 in S_reg /root/perl/regcomp.c​:11604​:10
  #125 0x137a079 in Perl_re_op_compile /root/perl/regcomp.c​:7197​:9
  #126 0x5cd95c in Perl_pmruntime /root/perl/op.c​:7025​:6
  #127 0x1271ef5 in Perl_yyparse /root/perl/perly.y​:1188​:23
  #128 0x9cc7ef in S_parse_body /root/perl/perl.c​:2563​:9
  #129 0x9a7d2d in perl_parse /root/perl/perl.c​:1857​:2
  #130 0x50d88c in main /root/perl/perlmain.c​:121​:10
  #131 0x7f2ff855d2b0 in __libc_start_main
(/lib/x86_64-linux-gnu/libc.so.6+0x202b0)
  #132 0x43cd49 in _start (/root/perl/perl+0x43cd49)

SUMMARY​: AddressSanitizer​: stack-overflow /root/perl/regcomp.c​:16224 in
S_regclass
==16663==ABORTING

Worth noting, if we set ulimit -s to 8243 and we put
m;(((((((((((((((((((((((((((((([ in test.pl and change the command line to
./perl -Dut test.pl, the stack overflow moves to perl/regcomp.c​:18983 in
S_regnode_guts​:

==6585==ERROR​: AddressSanitizer​: stack-overflow on address 0x7ffec4f3fc20
(pc 0x000001859402 bp 0x7ffec4f40920 sp 0x7ffec4f3fc20 T0)
  #0 0x1859401 in S_regnode_guts /root/perl/regcomp.c​:18983
  #1 0x177b02e in S_reganode /root/perl/regcomp.c​:19050​:27
  #2 0x194c7c1 in S_regclass /root/perl/regcomp.c​:16365​:11
  #3 0x189f764 in S_regatom /root/perl/regcomp.c​:12870​:15
  #4 0x186358b in S_regpiece /root/perl/regcomp.c​:11953​:11
  #5 0x17ac810 in S_regbranch /root/perl/regcomp.c​:11878​:18
  #6 0x1503f24 in S_reg /root/perl/regcomp.c​:11604​:10
  #7 0x18a66ca in S_regatom /root/perl/regcomp.c​:12894​:15
  #8 0x186358b in S_regpiece /root/perl/regcomp.c​:11953​:11
  #9 0x17ac810 in S_regbranch /root/perl/regcomp.c​:11878​:18
  #10 0x1503f24 in S_reg /root/perl/regcomp.c​:11604​:10
*SNIP*
  #125 0x17ac810 in S_regbranch /root/perl/regcomp.c​:11878​:18
  #126 0x1503f24 in S_reg /root/perl/regcomp.c​:11604​:10
  #127 0x137a079 in Perl_re_op_compile /root/perl/regcomp.c​:7197​:9
  #128 0x5cd95c in Perl_pmruntime /root/perl/op.c​:7025​:6
  #129 0x1271ef5 in Perl_yyparse /root/perl/perly.y​:1188​:23
  #130 0x9cc7ef in S_parse_body /root/perl/perl.c​:2563​:9
  #131 0x9a7d2d in perl_parse /root/perl/perl.c​:1857​:2
  #132 0x50d88c in main /root/perl/perlmain.c​:121​:10
  #133 0x7f04d796f2b0 in __libc_start_main
(/lib/x86_64-linux-gnu/libc.so.6+0x202b0)
  #134 0x43cd49 in _start (/root/perl/perl+0x43cd49)
SUMMARY​: AddressSanitizer​: stack-overflow /root/perl/regcomp.c​:18983 in
S_regnode_guts
==6585==ABORTING

@p5pRT
Copy link
Author

p5pRT commented Feb 20, 2018

From @demerphq

This is to a certain extent expected with current code. Every open parents
adds two stack frames. Unless we put significant effort into rewriting this
code there will always be some limit to the level of nesting we support.

On 20 Feb 2018 07​:27, "Brian Carpenter" <perlbug-followup@​perl.org> wrote​:

# New Ticket Created by Brian Carpenter
# Please include the string​: [perl #132884]
# in the subject line of all future correspondence about this issue.
# <URL​: https://rt-archive.perl.org/perl5/Ticket/Display.html?id=132884 >

perl v5.27.8-321-ge720636704 compiled with clang 7 trunk and
-fsanitize=address.

./perl -e 'm;(((((((((((((((((((((((((((((([' triggers a stack overflow
when ulimit -s = 8243 or less. If ulimit -s = 8244, we get Unmatched [ in
regex; marked by <-- HERE in m/(((((((((((((((((((((((((((((([ <-- HERE /
at test000.pl line 1.

AddressSanitizer​:DEADLYSIGNAL

==16663==ERROR​: AddressSanitizer​: stack-overflow on address 0x7ffdcd7a1f00
(pc 0x000001947519 bp 0x7ffdcd7bbcf0 sp 0x7ffdcd7a1f00 T0)
#0 0x1947518 in S_regclass /root/perl/regcomp.c​:16224
#1 0x189f764 in S_regatom /root/perl/regcomp.c​:12870​:15
#2 0x186358b in S_regpiece /root/perl/regcomp.c​:11953​:11
#3 0x17ac810 in S_regbranch /root/perl/regcomp.c​:11878​:18
#4 0x1503f24 in S_reg /root/perl/regcomp.c​:11604​:10
#5 0x18a66ca in S_regatom /root/perl/regcomp.c​:12894​:15
#6 0x186358b in S_regpiece /root/perl/regcomp.c​:11953​:11
#7 0x17ac810 in S_regbranch /root/perl/regcomp.c​:11878​:18
#8 0x1503f24 in S_reg /root/perl/regcomp.c​:11604​:10
#9 0x18a66ca in S_regatom /root/perl/regcomp.c​:12894​:15
#10 0x186358b in S_regpiece /root/perl/regcomp.c​:11953​:11
*SNIP*
#120 0x1503f24 in S_reg /root/perl/regcomp.c​:11604​:10
#121 0x18a66ca in S_regatom /root/perl/regcomp.c​:12894​:15
#122 0x186358b in S_regpiece /root/perl/regcomp.c​:11953​:11
#123 0x17ac810 in S_regbranch /root/perl/regcomp.c​:11878​:18
#124 0x1503f24 in S_reg /root/perl/regcomp.c​:11604​:10
#125 0x137a079 in Perl_re_op_compile /root/perl/regcomp.c​:7197​:9
#126 0x5cd95c in Perl_pmruntime /root/perl/op.c​:7025​:6
#127 0x1271ef5 in Perl_yyparse /root/perl/perly.y​:1188​:23
#128 0x9cc7ef in S_parse_body /root/perl/perl.c​:2563​:9
#129 0x9a7d2d in perl_parse /root/perl/perl.c​:1857​:2
#130 0x50d88c in main /root/perl/perlmain.c​:121​:10
#131 0x7f2ff855d2b0 in __libc_start_main
(/lib/x86_64-linux-gnu/libc.so.6+0x202b0)
#132 0x43cd49 in _start (/root/perl/perl+0x43cd49)

SUMMARY​: AddressSanitizer​: stack-overflow /root/perl/regcomp.c​:16224 in
S_regclass
==16663==ABORTING

Worth noting, if we set ulimit -s to 8243 and we put
m;(((((((((((((((((((((((((((((([ in test.pl and change the command line
to
./perl -Dut test.pl, the stack overflow moves to perl/regcomp.c​:18983 in
S_regnode_guts​:

==6585==ERROR​: AddressSanitizer​: stack-overflow on address 0x7ffec4f3fc20
(pc 0x000001859402 bp 0x7ffec4f40920 sp 0x7ffec4f3fc20 T0)
#0 0x1859401 in S_regnode_guts /root/perl/regcomp.c​:18983
#1 0x177b02e in S_reganode /root/perl/regcomp.c​:19050​:27
#2 0x194c7c1 in S_regclass /root/perl/regcomp.c​:16365​:11
#3 0x189f764 in S_regatom /root/perl/regcomp.c​:12870​:15
#4 0x186358b in S_regpiece /root/perl/regcomp.c​:11953​:11
#5 0x17ac810 in S_regbranch /root/perl/regcomp.c​:11878​:18
#6 0x1503f24 in S_reg /root/perl/regcomp.c​:11604​:10
#7 0x18a66ca in S_regatom /root/perl/regcomp.c​:12894​:15
#8 0x186358b in S_regpiece /root/perl/regcomp.c​:11953​:11
#9 0x17ac810 in S_regbranch /root/perl/regcomp.c​:11878​:18
#10 0x1503f24 in S_reg /root/perl/regcomp.c​:11604​:10
*SNIP*
#125 0x17ac810 in S_regbranch /root/perl/regcomp.c​:11878​:18
#126 0x1503f24 in S_reg /root/perl/regcomp.c​:11604​:10
#127 0x137a079 in Perl_re_op_compile /root/perl/regcomp.c​:7197​:9
#128 0x5cd95c in Perl_pmruntime /root/perl/op.c​:7025​:6
#129 0x1271ef5 in Perl_yyparse /root/perl/perly.y​:1188​:23
#130 0x9cc7ef in S_parse_body /root/perl/perl.c​:2563​:9
#131 0x9a7d2d in perl_parse /root/perl/perl.c​:1857​:2
#132 0x50d88c in main /root/perl/perlmain.c​:121​:10
#133 0x7f04d796f2b0 in __libc_start_main
(/lib/x86_64-linux-gnu/libc.so.6+0x202b0)
#134 0x43cd49 in _start (/root/perl/perl+0x43cd49)
SUMMARY​: AddressSanitizer​: stack-overflow /root/perl/regcomp.c​:18983 in
S_regnode_guts
==6585==ABORTING

@p5pRT
Copy link
Author

p5pRT commented Feb 20, 2018

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

@p5pRT
Copy link
Author

p5pRT commented Feb 23, 2018

From @khwilliamson

On Mon, 19 Feb 2018 17​:03​:58 -0800, demerphq wrote​:

This is to a certain extent expected with current code. Every open parents
adds two stack frames. Unless we put significant effort into rewriting this
code there will always be some limit to the level of nesting we support.

On 20 Feb 2018 07​:27, "Brian Carpenter" <perlbug-followup@​perl.org> wrote​:

# New Ticket Created by Brian Carpenter
# Please include the string​: [perl #132884]
# in the subject line of all future correspondence about this issue.
# <URL​: https://rt-archive.perl.org/perl5/Ticket/Display.html?id=132884 >

perl v5.27.8-321-ge720636704 compiled with clang 7 trunk and
-fsanitize=address.

./perl -e 'm;(((((((((((((((((((((((((((((([' triggers a stack overflow
when ulimit -s = 8243 or less. If ulimit -s = 8244, we get Unmatched [ in
regex; marked by <-- HERE in m/(((((((((((((((((((((((((((((([ <-- HERE /
at test000.pl line 1.

AddressSanitizer​:DEADLYSIGNAL

==16663==ERROR​: AddressSanitizer​: stack-overflow on address 0x7ffdcd7a1f00
(pc 0x000001947519 bp 0x7ffdcd7bbcf0 sp 0x7ffdcd7a1f00 T0)
#0 0x1947518 in S_regclass /root/perl/regcomp.c​:16224
#1 0x189f764 in S_regatom /root/perl/regcomp.c​:12870​:15
#2 0x186358b in S_regpiece /root/perl/regcomp.c​:11953​:11
#3 0x17ac810 in S_regbranch /root/perl/regcomp.c​:11878​:18
#4 0x1503f24 in S_reg /root/perl/regcomp.c​:11604​:10
#5 0x18a66ca in S_regatom /root/perl/regcomp.c​:12894​:15
#6 0x186358b in S_regpiece /root/perl/regcomp.c​:11953​:11
#7 0x17ac810 in S_regbranch /root/perl/regcomp.c​:11878​:18
#8 0x1503f24 in S_reg /root/perl/regcomp.c​:11604​:10
#9 0x18a66ca in S_regatom /root/perl/regcomp.c​:12894​:15
#10 0x186358b in S_regpiece /root/perl/regcomp.c​:11953​:11
*SNIP*
#120 0x1503f24 in S_reg /root/perl/regcomp.c​:11604​:10
#121 0x18a66ca in S_regatom /root/perl/regcomp.c​:12894​:15
#122 0x186358b in S_regpiece /root/perl/regcomp.c​:11953​:11
#123 0x17ac810 in S_regbranch /root/perl/regcomp.c​:11878​:18
#124 0x1503f24 in S_reg /root/perl/regcomp.c​:11604​:10
#125 0x137a079 in Perl_re_op_compile /root/perl/regcomp.c​:7197​:9
#126 0x5cd95c in Perl_pmruntime /root/perl/op.c​:7025​:6
#127 0x1271ef5 in Perl_yyparse /root/perl/perly.y​:1188​:23
#128 0x9cc7ef in S_parse_body /root/perl/perl.c​:2563​:9
#129 0x9a7d2d in perl_parse /root/perl/perl.c​:1857​:2
#130 0x50d88c in main /root/perl/perlmain.c​:121​:10
#131 0x7f2ff855d2b0 in __libc_start_main
(/lib/x86_64-linux-gnu/libc.so.6+0x202b0)
#132 0x43cd49 in _start (/root/perl/perl+0x43cd49)

SUMMARY​: AddressSanitizer​: stack-overflow /root/perl/regcomp.c​:16224 in
S_regclass
==16663==ABORTING

Worth noting, if we set ulimit -s to 8243 and we put
m;(((((((((((((((((((((((((((((([ in test.pl and change the command line
to
./perl -Dut test.pl, the stack overflow moves to perl/regcomp.c​:18983 in
S_regnode_guts​:

==6585==ERROR​: AddressSanitizer​: stack-overflow on address 0x7ffec4f3fc20
(pc 0x000001859402 bp 0x7ffec4f40920 sp 0x7ffec4f3fc20 T0)
#0 0x1859401 in S_regnode_guts /root/perl/regcomp.c​:18983
#1 0x177b02e in S_reganode /root/perl/regcomp.c​:19050​:27
#2 0x194c7c1 in S_regclass /root/perl/regcomp.c​:16365​:11
#3 0x189f764 in S_regatom /root/perl/regcomp.c​:12870​:15
#4 0x186358b in S_regpiece /root/perl/regcomp.c​:11953​:11
#5 0x17ac810 in S_regbranch /root/perl/regcomp.c​:11878​:18
#6 0x1503f24 in S_reg /root/perl/regcomp.c​:11604​:10
#7 0x18a66ca in S_regatom /root/perl/regcomp.c​:12894​:15
#8 0x186358b in S_regpiece /root/perl/regcomp.c​:11953​:11
#9 0x17ac810 in S_regbranch /root/perl/regcomp.c​:11878​:18
#10 0x1503f24 in S_reg /root/perl/regcomp.c​:11604​:10
*SNIP*
#125 0x17ac810 in S_regbranch /root/perl/regcomp.c​:11878​:18
#126 0x1503f24 in S_reg /root/perl/regcomp.c​:11604​:10
#127 0x137a079 in Perl_re_op_compile /root/perl/regcomp.c​:7197​:9
#128 0x5cd95c in Perl_pmruntime /root/perl/op.c​:7025​:6
#129 0x1271ef5 in Perl_yyparse /root/perl/perly.y​:1188​:23
#130 0x9cc7ef in S_parse_body /root/perl/perl.c​:2563​:9
#131 0x9a7d2d in perl_parse /root/perl/perl.c​:1857​:2
#132 0x50d88c in main /root/perl/perlmain.c​:121​:10
#133 0x7f04d796f2b0 in __libc_start_main
(/lib/x86_64-linux-gnu/libc.so.6+0x202b0)
#134 0x43cd49 in _start (/root/perl/perl+0x43cd49)
SUMMARY​: AddressSanitizer​: stack-overflow /root/perl/regcomp.c​:18983 in
S_regnode_guts
==6585==ABORTING

I think this ticket should be rejected, and will do so in a week unless objection is made
--
Karl Williamson

@p5pRT
Copy link
Author

p5pRT commented Feb 23, 2018

From @demerphq

Maybe change it to a feature request?

On 23 Feb 2018 13​:57, "Karl Williamson via RT" <perlbug-followup@​perl.org>
wrote​:

On Mon, 19 Feb 2018 17​:03​:58 -0800, demerphq wrote​:

This is to a certain extent expected with current code. Every open parents
adds two stack frames. Unless we put significant effort into rewriting
this
code there will always be some limit to the level of nesting we support.

On 20 Feb 2018 07​:27, "Brian Carpenter" <perlbug-followup@​perl.org> wrote​:

# New Ticket Created by Brian Carpenter
# Please include the string​: [perl #132884]
# in the subject line of all future correspondence about this issue.
# <URL​: https://rt-archive.perl.org/perl5/Ticket/Display.html?id=132884 >

perl v5.27.8-321-ge720636704 compiled with clang 7 trunk and
-fsanitize=address.

./perl -e 'm;(((((((((((((((((((((((((((((([' triggers a stack overflow
when ulimit -s = 8243 or less. If ulimit -s = 8244, we get Unmatched [
in
regex; marked by <-- HERE in m/(((((((((((((((((((((((((((((([ <-- HERE
/
at test000.pl line 1.

AddressSanitizer​:DEADLYSIGNAL

==16663==ERROR​: AddressSanitizer​: stack-overflow on address
0x7ffdcd7a1f00
(pc 0x000001947519 bp 0x7ffdcd7bbcf0 sp 0x7ffdcd7a1f00 T0)
#0 0x1947518 in S_regclass /root/perl/regcomp.c​:16224
#1 0x189f764 in S_regatom /root/perl/regcomp.c​:12870​:15
#2 0x186358b in S_regpiece /root/perl/regcomp.c​:11953​:11
#3 0x17ac810 in S_regbranch /root/perl/regcomp.c​:11878​:18
#4 0x1503f24 in S_reg /root/perl/regcomp.c​:11604​:10
#5 0x18a66ca in S_regatom /root/perl/regcomp.c​:12894​:15
#6 0x186358b in S_regpiece /root/perl/regcomp.c​:11953​:11
#7 0x17ac810 in S_regbranch /root/perl/regcomp.c​:11878​:18
#8 0x1503f24 in S_reg /root/perl/regcomp.c​:11604​:10
#9 0x18a66ca in S_regatom /root/perl/regcomp.c​:12894​:15
#10 0x186358b in S_regpiece /root/perl/regcomp.c​:11953​:11
*SNIP*
#120 0x1503f24 in S_reg /root/perl/regcomp.c​:11604​:10
#121 0x18a66ca in S_regatom /root/perl/regcomp.c​:12894​:15
#122 0x186358b in S_regpiece /root/perl/regcomp.c​:11953​:11
#123 0x17ac810 in S_regbranch /root/perl/regcomp.c​:11878​:18
#124 0x1503f24 in S_reg /root/perl/regcomp.c​:11604​:10
#125 0x137a079 in Perl_re_op_compile /root/perl/regcomp.c​:7197​:9
#126 0x5cd95c in Perl_pmruntime /root/perl/op.c​:7025​:6
#127 0x1271ef5 in Perl_yyparse /root/perl/perly.y​:1188​:23
#128 0x9cc7ef in S_parse_body /root/perl/perl.c​:2563​:9
#129 0x9a7d2d in perl_parse /root/perl/perl.c​:1857​:2
#130 0x50d88c in main /root/perl/perlmain.c​:121​:10
#131 0x7f2ff855d2b0 in __libc_start_main
(/lib/x86_64-linux-gnu/libc.so.6+0x202b0)
#132 0x43cd49 in _start (/root/perl/perl+0x43cd49)

SUMMARY​: AddressSanitizer​: stack-overflow /root/perl/regcomp.c​:16224 in
S_regclass
==16663==ABORTING

Worth noting, if we set ulimit -s to 8243 and we put
m;(((((((((((((((((((((((((((((([ in test.pl and change the command line
to
./perl -Dut test.pl, the stack overflow moves to perl/regcomp.c​:18983 in
S_regnode_guts​:

==6585==ERROR​: AddressSanitizer​: stack-overflow on address
0x7ffec4f3fc20
(pc 0x000001859402 bp 0x7ffec4f40920 sp 0x7ffec4f3fc20 T0)
#0 0x1859401 in S_regnode_guts /root/perl/regcomp.c​:18983
#1 0x177b02e in S_reganode /root/perl/regcomp.c​:19050​:27
#2 0x194c7c1 in S_regclass /root/perl/regcomp.c​:16365​:11
#3 0x189f764 in S_regatom /root/perl/regcomp.c​:12870​:15
#4 0x186358b in S_regpiece /root/perl/regcomp.c​:11953​:11
#5 0x17ac810 in S_regbranch /root/perl/regcomp.c​:11878​:18
#6 0x1503f24 in S_reg /root/perl/regcomp.c​:11604​:10
#7 0x18a66ca in S_regatom /root/perl/regcomp.c​:12894​:15
#8 0x186358b in S_regpiece /root/perl/regcomp.c​:11953​:11
#9 0x17ac810 in S_regbranch /root/perl/regcomp.c​:11878​:18
#10 0x1503f24 in S_reg /root/perl/regcomp.c​:11604​:10
*SNIP*
#125 0x17ac810 in S_regbranch /root/perl/regcomp.c​:11878​:18
#126 0x1503f24 in S_reg /root/perl/regcomp.c​:11604​:10
#127 0x137a079 in Perl_re_op_compile /root/perl/regcomp.c​:7197​:9
#128 0x5cd95c in Perl_pmruntime /root/perl/op.c​:7025​:6
#129 0x1271ef5 in Perl_yyparse /root/perl/perly.y​:1188​:23
#130 0x9cc7ef in S_parse_body /root/perl/perl.c​:2563​:9
#131 0x9a7d2d in perl_parse /root/perl/perl.c​:1857​:2
#132 0x50d88c in main /root/perl/perlmain.c​:121​:10
#133 0x7f04d796f2b0 in __libc_start_main
(/lib/x86_64-linux-gnu/libc.so.6+0x202b0)
#134 0x43cd49 in _start (/root/perl/perl+0x43cd49)
SUMMARY​: AddressSanitizer​: stack-overflow /root/perl/regcomp.c​:18983 in
S_regnode_guts
==6585==ABORTING

I think this ticket should be rejected, and will do so in a week unless
objection is made
--
Karl Williamson


via perlbug​: queue​: perl5 status​: open
https://rt-archive.perl.org/perl5/Ticket/Display.html?id=132884

@p5pRT
Copy link
Author

p5pRT commented Mar 4, 2018

From @khwilliamson

Added to wishlist
--
Karl Williamson

@p5pRT
Copy link
Author

p5pRT commented Mar 14, 2018

From @khwilliamson

On Thu, 15 Jun 2017 18​:02​:05 -0700, tonyc wrote​:

On Tue, 13 Jun 2017 17​:14​:43 -0700, demerphq wrote​:

And looking a little closer I remember I added depth counts to all
these subs some years back, which means that adding a depth check is
trivial.

The only question is what should the maximum depth be, and should it
be set at compile time or at run time? If it is compile time and the
value is too large then people will still see segfaults, on the other
hand, if we allow people to set it at run time (through a magic var
somewhere, maybe ${^MAX_REGEX_PAREN_NESTING}) then they can adjust to
taste given their context.

I have to admit I lean towards setting it to a number like 1000, where
it is unlikely to break many programs but is also unlikely to blow out
anybodies stack. (Note we add four stack frames for each '(' we
encounter.)

1000 seems like a reasonable default limit.

Making it runtime adjustable would be good if it isn't too much effort, so
if someone explicitly sets a large stack (as with ulimit -s) they can have
more depth.

Tony

It seems to me like we should apply the patch.
--
Karl Williamson

@p5pRT
Copy link
Author

p5pRT commented Mar 18, 2019

From @khwilliamson

This has been fixed by
commit 6ef7fe5
Author​: Karl Williamson <khw@​cpan.org>
Date​: Sun Mar 17 22​:11​:04 2019 -0600

  PATCH​: [perl #131551] Too deep regex compilation recursion
 
  This patch, started by Yves Orton, and refined in consultation with Tony
  Cook, imposes a maximum depth of unclosed left parentheses, at which
  point it croaks. This is to prevent the segfault in the ticket.
 
  The patch adds a variable that can be set to increase or decrease this
  limit at run time (actually regex compilation time) should this be
  desired, and hence our pre-determined limit of 1000 can be changed if
  necessary.
--
Karl Williamson

@p5pRT
Copy link
Author

p5pRT commented Mar 18, 2019

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

@p5pRT
Copy link
Author

p5pRT commented Mar 18, 2019

From @khwilliamson

On Sun, 04 Mar 2018 08​:49​:01 -0800, khw wrote​:

Added to wishlist

I believe that perl #131551 addresses this, and will merge this ticket to that one in a month-ish if I don't hear arguments to the contrary
--
Karl Williamson

@p5pRT
Copy link
Author

p5pRT commented May 22, 2019

From @khwilliamson

Thank you for filing this report. You have helped make Perl better.

With the release today of Perl 5.30.0, this and 160 other issues have been
resolved.

Perl 5.30.0 may be downloaded via​:
https://metacpan.org/release/XSAWYERX/perl-5.30.0

If you find that the problem persists, feel free to reopen this ticket.

@p5pRT
Copy link
Author

p5pRT commented May 22, 2019

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant