develooper Front page | perl.perl5.porters | Postings from February 2019

[perl #133334] #2 AddressSanitizer: heap-use-after-free on address0x606000046d00 at pc 0x000000ef95ec bp 0x7ffe2a7856f0 sp 0x7ffe2a7856e8 READof size 8

From:
Tony Cook via RT
Date:
February 11, 2019 00:08
Subject:
[perl #133334] #2 AddressSanitizer: heap-use-after-free on address0x606000046d00 at pc 0x000000ef95ec bp 0x7ffe2a7856f0 sp 0x7ffe2a7856e8 READof size 8
Message ID:
rt-4.0.24-31915-1549843710-1388.133334-15-0@perl.org
On Thu, 02 Aug 2018 22:07:02 -0700, tonyc wrote:
> On Tue, 17 Jul 2018 07:02:45 -0700, hv wrote:
> > On Fri, 13 Jul 2018 03:39:46 -0700, hv wrote:
> > > This reduces at least to:
> > >   ./miniperl -Ilib -e '*L:: = *0; $x = *L::; *S:: = *::; %$x =
> > > *S::;
> > > *S:: = *::'
> >
> > I feel I've got a little further with this. I set PERL_HASH_SEED for
> > stability.
> >
> > This still SEGVs in the same place:
> > % PERL_HASH_SEED=1 ./miniperl -Do -e '
> >   *bad_stash:: = *non_stash;
> >   delete @::{grep !/^(bad_stash|recursive_stash)::$/, keys %::};
> >   *recursive_stash:: = \%::;
> >   %{*non_stash} = ();
> >   *recursive_stash:: = \%::
> > '
> >
> > I suspect that it boils down to something like: both the initial
> > *bad_stash::=*non_stash and the later %{*non_stash}=() leave
> > %bad_stash:: as something not properly initialised as a stash; it
> > does
> > get properly initialised at the point it is needed, but in this case
> > we are reaching it twice in the same operation (as
> > recursive_stash::bad_stash and
> > recursive_stash::recursive_stash::bad_stash) and the first and second
> > attempt are interacting badly.
> >
> > If that's correct, it may well be that the bad interaction relates to
> > the seen_stashes logic in mro_gather_and_rename:
> >     /* We use the seen_stashes hash to keep track of which packages
> > have
> >        been encountered so far. [...]
> > .. possibly along with the isa-restoration in mro_package_moved
> > (comment starting "We have to restore the original meta->isa").
> >
> > Nothing I've seen so far suggests to me there is a credible security
> > issue here, but I'm far from understanding it well enough to call it.
> 
> I don't think this is a security issue.

No objections heard, so now public.

Tony

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



nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About