Segfault when leaving smartmatch'ed sub #16608

p5pRT · 2018-07-05T03:50:41Z

Migrated from rt.perl.org#133330 (status was 'open')

Searchable as RT133330$

p5pRT · 2018-07-05T03:50:41Z

From @dur-randir

Created by @dur-randir

This test case was originally found with afl and then I've expanded it
for other loop control operators. All following programs cause perl to
crash/panic:

0sub{redo} for 0
FOO: 0sub{goto FOO} for 0
0sub{next} for 0
0sub{last} for 0

Perl Info


Flags:
    category=core
    severity=low

Site configuration information for perl 5.29.0:

Configured by root at Mon Jun 25 01:11:54 MSK 2018.

Summary of my perl5 (revision 5 version 29 subversion 0) configuration:
  Commit id: d361a1e6288b3e67fba6cb9f5cdac3737a1e3795
  Platform:
    osname=linux
    osvers=4.9.0-6-amd64
    archname=x86_64-linux
    uname='linux dorothy 4.9.0-6-amd64 #1 smp debian 4.9.88-1+deb9u1
(2018-05-07) x86_64 gnulinux '
    config_args='-des -Dusedevel -Dcc=afl-clang-fast -Doptimize=-O3 -g
-fno-omit-frame-pointer'
    hint=recommended
    useposix=true
    d_sigaction=define
    useithreads=undef
    usemultiplicity=undef
    use64bitint=define
    use64bitall=define
    uselongdouble=undef
    usemymalloc=n
    default_inc_excludes_dot=define
    bincompat5005=undef
  Compiler:
    cc='afl-clang-fast'
    ccflags ='-fno-strict-aliasing -pipe -fstack-protector-strong
-I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
-D_FORTIFY_SOURCE=2'
    optimize='-O3 -g -fno-omit-frame-pointer'
    cppflags='-fno-strict-aliasing -pipe -fstack-protector-strong
-I/usr/local/include'
    ccversion=''
    gccversion='4.2.1 Compatible Clang 3.9.1 (tags/RELEASE_391/rc2)'
    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='double'
    nvsize=8
    Off_t='off_t'
    lseeksize=8
    alignbytes=8
    prototype=define
  Linker and Libraries:
    ld='afl-clang-fast'
    ldflags =' -fstack-protector-strong -L/usr/local/lib'
    libpth=/usr/local/lib /usr/lib/llvm-3.9/bin/../lib/clang/3.9.1/lib
/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.24.so
    so=so
    useshrplib=false
    libperl=libperl.a
    gnulibc_version='2.24'
  Dynamic Linking:
    dlsrc=dl_dlopen.xs
    dlext=so
    d_dlsymun=undef
    ccdlflags='-Wl,-E'
    cccdlflags='-fPIC'
    lddlflags='-shared -O3 -g -fno-omit-frame-pointer -L/usr/local/lib
-fstack-protector-strong'



@INC for perl 5.29.0:
    lib
    /usr/local/lib/perl5/site_perl/5.29.0/x86_64-linux
    /usr/local/lib/perl5/site_perl/5.29.0
    /usr/local/lib/perl5/5.29.0/x86_64-linux
    /usr/local/lib/perl5/5.29.0


Environment for perl 5.29.0:
    HOME=/home/afl
    LANG=en_US.UTF-8
    LANGUAGE=en_US:en
    LC_CTYPE=en_US.UTF-8
    LD_LIBRARY_PATH (unset)
    LOGDIR (unset)
    PATH=/home/afl/perlbrew/bin:/home/afl/perlbrew/perls/perl-5.20.2/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
    PERLBREW_BASHRC_VERSION=0.78
    PERLBREW_HOME=/home/afl/.perlbrew
    PERLBREW_MANPATH=/home/afl/perlbrew/perls/perl-5.20.2/man
    PERLBREW_PATH=/home/afl/perlbrew/bin:/home/afl/perlbrew/perls/perl-5.20.2/bin
    PERLBREW_PERL=perl-5.20.2
    PERLBREW_ROOT=/home/afl/perlbrew
    PERLBREW_VERSION=0.78
    PERL_BADLANG (unset)
    SHELL=/usr/bin/zsh

p5pRT · 2018-09-03T17:27:50Z

From @jkeenan

On Thu, 05 Jul 2018 03:50:41 GMT, randir wrote:

This is a bug report for perl from sergey.aleynikov@gmail.com,
generated with the help of perlbug 1.41 running under perl 5.29.0.

-----------------------------------------------------------------
[Please describe your issue here]

This test case was originally found with afl and then I've expanded it
for other loop control operators. All following programs cause perl to
crash/panic:

0sub{redo} for 0
FOO: 0sub{goto FOO} for 0
0sub{next} for 0
0sub{last} for 0

Confirmed with an unthreaded 5.28.0:

#####
$ perl -e '0~~sub{redo} for 0'
Smartmatch is experimental at -e line 1.
Segmentation fault (core dumped)

$ perl -e 'FOO: 0~~sub{goto FOO} for 0'
Smartmatch is experimental at -e line 1.
Segmentation fault (core dumped)

$ perl -e '0~~sub{next} for 0'
Smartmatch is experimental at -e line 1.
panic: pp_iter, type=0.

$ perl -e '0~~sub{last} for 0'
Smartmatch is experimental at -e line 1.
panic: pp_iter, type=0.
#####

Thank you very much.

--
James E Keenan (jkeenan@cpan.org)

p5pRT · 2018-09-03T17:27:51Z

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

tonycoz · 2025-04-09T00:30:27Z

From what I can tell dopoptoloop() or dopoptolabel() is unwinding the context and save stacks past where the call_sv() is done.

We've added special handling for defer callbacks, but I can see this being a general problem for all call_sv()s when the called sub does a loop exit.

defer, which also uses call_sv() has it's own handling for dopopto*().

Class initialization can crash in a similar way:

$ ./perl -Ilib -Mfeature=class -e 'sub f { last } class X { field $x = ::f(); } new X for 0'
class is experimental at -e line 1.
field is experimental at -e line 1.
perl: hv.c:2517: Perl_hv_iterinit: Assertion `SvTYPE(hv) == SVt_PVHV' failed.
Aborted

Other call_sv()s in core all seem to use PUSHSTACKi()/push_stackinfo() which starts a new context stack and prevents finding the outer loop, preventing the crash.

dopoptoloop() or dopoptolabel() would find a loop outside the sub called from call_sv() and rewind the context and save stack to outside the context set up by call_sv(), crashes and panics ensure. Switching stacks here also starts a new context stack, so the outer loop isn't found and we don't crash. Most other callers to call_sv() (or call_method() etc) do the same. I'm not entirely sure about passing flags = 1 to push_stackinfo(), this matches pp_sort, but not other callers. Fixes Perl#16608

Using last, next etc would pop the context stack to above the call_sv(), generally resulting in a crash or assertion failure. The search the context to pop to stops at the top of the current context stack, and PUSHSTACKi() switches to a new stack, preventing the search from finding any loop outside the call_sv() Similar to Perl#16608

Using last, next etc would pop the context stack to above the call_sv(), generally resulting in a crash or assertion failure. The search the context to pop to stops at the top of the current context stack, and PUSHSTACKi() switches to a new stack, preventing the search from finding any loop outside the call_sv() Similar to #16608

dopoptoloop() or dopoptolabel() would find a loop outside the sub called from call_sv() and rewind the context and save stack to outside the context set up by call_sv(), crashes and panics ensure. Switching stacks here also starts a new context stack, so the outer loop isn't found and we don't crash. Most other callers to call_sv() (or call_method() etc) do the same. I'm not entirely sure about passing flags = 1 to push_stackinfo(), this matches pp_sort, but not other callers. Fixes Perl#16608

Using last, next etc would pop the context stack to above the call_sv(), generally resulting in a crash or assertion failure. The search the context to pop to stops at the top of the current context stack, and PUSHSTACKi() switches to a new stack, preventing the search from finding any loop outside the call_sv() Similar to Perl#16608

dopoptoloop() or dopoptolabel() would find a loop outside the sub called from call_sv() and rewind the context and save stack to outside the context set up by call_sv(), crashes and panics ensure. Switching stacks here also starts a new context stack, so the outer loop isn't found and we don't crash. Most other callers to call_sv() (or call_method() etc) do the same. I'm not entirely sure about passing flags = 1 to push_stackinfo(), this matches pp_sort, but not other callers. Fixes Perl#16608

Using last, next etc would pop the context stack to above the call_sv(), generally resulting in a crash or assertion failure. The search the context to pop to stops at the top of the current context stack, and PUSHSTACKi() switches to a new stack, preventing the search from finding any loop outside the call_sv() Similar to Perl#16608

dopoptoloop() or dopoptolabel() would find a loop outside the sub called from call_sv() and rewind the context and save stack to outside the context set up by call_sv(), crashes and panics ensure. Switching stacks here also starts a new context stack, so the outer loop isn't found and we don't crash. Most other callers to call_sv() (or call_method() etc) do the same. I'm not entirely sure about passing flags = 1 to push_stackinfo(), this matches pp_sort, but not other callers. Fixes #16608

Using last, next etc would pop the context stack to above the call_sv(), generally resulting in a crash or assertion failure. The search the context to pop to stops at the top of the current context stack, and PUSHSTACKi() switches to a new stack, preventing the search from finding any loop outside the call_sv() Similar to #16608

p5pRT added Severity Low type-core labels Oct 19, 2019

xenu removed the affects-5.29 label Nov 19, 2021

xenu removed the Severity Low label Dec 29, 2021

khwilliamson added the segfault label Apr 17, 2022

tonycoz self-assigned this Jan 4, 2024

tonycoz mentioned this issue Apr 16, 2025

Prevent loop exits from unwinding the context/scope stacks beyond a call_sv for smartmatch subs and class constructors #23204

Merged

mauke closed this as completed in #23204 Apr 19, 2025

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Segfault when leaving smartmatch'ed sub #16608

Segfault when leaving smartmatch'ed sub #16608

p5pRT commented Jul 5, 2018

p5pRT commented Jul 5, 2018

p5pRT commented Sep 3, 2018

p5pRT commented Sep 3, 2018

tonycoz commented Apr 9, 2025 •

edited

Loading

Segfault when leaving smartmatch'ed sub #16608

Segfault when leaving smartmatch'ed sub #16608

Comments

p5pRT commented Jul 5, 2018

p5pRT commented Jul 5, 2018

From @dur-randir

Created by @dur-randir

p5pRT commented Sep 3, 2018

From @jkeenan

p5pRT commented Sep 3, 2018

tonycoz commented Apr 9, 2025 • edited Loading

tonycoz commented Apr 9, 2025 •

edited

Loading