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
Taint-mode assert fail in Perl_magic_clearisa without other symptoms #15365
Comments
From @dcollinsnGreetings Porters, I have compiled bleadperl with the afl-gcc compiler using: ./Configure -Dusedevel -Dprefix='/usr/local/perl-afl' -Dcc='ccache afl-gcc' -Uuselongdouble -Duse64bitall -Doptimize=-g -Uversiononly -Uman1dir -Uman3dir -Dusequadmath -des 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 an assert fail in debug buids of the perl interpreter. The testcase is the file below. On normal builds, this runs normally (albeit with an expected warning). On debug builds, this returns an assert fail. dcollins@nightshade64:~/perl$ ./perl -Ilib -tW -e '{@{*a::ISA}=undef*a::ISA;@a::ISA=0}' dcollins@nightshade64:~/perldebug$ ./perl -Ilib -tW -e '{@{*a::ISA}=undef*a::ISA;@a::ISA=0}' Debugging tool output is below. A git bisect was performed and reported the following. 5e267fb is the first bad commit Always copy return values when exiting scope v5.14.0-642-g3ed94dc fixed certain instances where returning from a sub sub f { delete $foo{bar} } This was because if the value(s) being returned had SvTEMP set, copying However, this applies equally well to other scope exits, for example do { ...; delete $foo{bar} } So this commits adds the RC==1 test to S_leave_common() too, which handles Note that S_leave_common() also sometimes skips on PADTMPs as well as :100644 100644 82189bb5c188e77800176fe8cfcb80b15bcb2226 d1229af7609c41d1caa7944f8d90eb6a2b12859c M pp_ctl.c **GDB** dcollins@nightshade64:~/perldebug$ gdb --args ./perl -Ilib -tW -e '{@{*a::ISA}=undef*a::ISA;@a::ISA=0}' Program received signal SIGABRT, Aborted. **VALGRIND** No reported memory management errors. **PERL -V** dcollins@nightshade64:~/perldebug$ ./perl -Ilib -V Characteristics of this binary (from libperl): |
From @iabynOn Thu, May 26, 2016 at 05:29:21PM -0700, Dan Collins wrote:
It's equivalent to the following: perl -t run against: undef *a::ISA; The problem is in the weak pointer from ISA magic to the GV, i.e. where However, with this: @{*a::ISA}, the *a::ISA expression is executed within At the next statement boundary temps are freed, and @a::ISA's mg_obj I don't know how to fix this. -- |
The RT System itself - Status changed from 'new' to 'open' |
From zefram@fysh.orgDave Mitchell wrote:
The GP has a pointer to the interned (`effective') GV from which any -zefram |
From @cpansproutOn Mon Jun 27 08:54:23 2016, davem wrote:
Why does it only happen under -t and -T? -- Father Chrysostomos |
From @iabynOn Mon, Jun 27, 2016 at 05:58:15PM -0700, Father Chrysostomos via RT wrote:
I just checked. In the absence of -t, the @{*a::ISA} is compiled with -- |
From @iabynOn Mon, Jun 27, 2016 at 05:27:05PM +0100, Zefram wrote:
That won't work in a case like: *Bar::ISA = *Foo::ISA When the ISA array is modified, both stashes need mro_isa_changed_in() At the moment, mg_obj normally points to the ISA AV's GV, but when there But the current scheme will (I imagine) fail in the case of something $Bar::{ISA} = $Foo::{ISA}; Perhaps instead of storing GV or GP pointer(s) in the ISA magic, -- |
From @cpansproutOn Tue Jun 28 02:35:26 2016, davem wrote:
It’s practically impossible for perl to track things correctly when people do direct stash assignment. (That’s partly why perlmod says: The results of creating new symbol table entries directly or modifying any ) So as long as that case does not crash, I think that’s fine.
As long as things still work when stashes get effectively renamed (Bar gets renamed in *Foo::=*Bar::, *Bar::=*Baz::). I went to great lengths to make sure that worked (in 5.12, iirc), and I would hate to see it break. -- Father Chrysostomos |
Migrated from rt.perl.org#128254 (status was 'open')
Searchable as RT128254$
The text was updated successfully, but these errors were encountered: