[perl #113486] CopSTASH can point to freed-and-reused SV

On Sun Jun 03 18:32:35 2012, sprout wrote:
> On non-threaded builds, cops have a direct pointer to their stash,
>    which is not reference-counted.
> 
> caller returns undef in that case:
> 
> $ ./perl -ILib -e 'package foo { sub bar { main::bar() } } sub bar {
>    delete $::{"foo::"}; warn scalar caller }; foo::bar'
> Warning: something's wrong at -e line 1.
> 
> But it returns undef by accident.  cop_stash is pointing to a freed
>    scalar, which is not SvOOK, so HvNAME_HEK returns false.
> 
> I haven’t come up with a test case yet, but the freed scalar could be
>    reused for another stash, giving erroneous results.

I’m wondering whether this is even worth fixing.

For non-threaded perls, it would require modifying any remaining op
trees when freeing hashes.  It would probably then require every stash
to have symtab magic attached to it.

Under threads, we would have to make cops hold a refcount on the
PL_stashpad slot so we know when it can be reused.

Having cops hold a refcount on the stash would result in too many
circular references, so that’s a not a good option.

> Or it could be
>    used for a scalar with the offset hack applied, which would result
>    in crashes.

{ package foo; sub bar { main::bar() } }
sub bar {
    delete $::{"foo::"};
    my $x = \($1+2);
    my $y = \($1+2); # this is the one that reuses the mem addr, but
    my $z = \($1+2);  # try the others just in case
    s/2// for $$x, $$y, $$z; # now SvOOK
    warn scalar caller # boom
};
foo::bar

I’ve fixed that in commit e788621.

> In fixing another bug, there is a chance I will extend this bug to
>    threaded perls, too.

Which I have done.  But fixing that other bug actually fixed about three
bugs at once.

-- 

Father Chrysostomos

• [perl #113486] CopSTASH can point to freed-and-reused SV by Father Chrysostomos via RT
• [perl #113486] CopSTASH can point to freed-and-reused SV by Father Chrysostomos