This is a live mirror of the Perl 5 development currently hosted at https://github.com/perl/perl5
In Perl_gp_free() use PL_tmps_stack to avoid freeing glob entries immediately.
authorNicholas Clark <nick@ccl4.org>
Fri, 2 Jul 2021 09:55:00 +0000 (09:55 +0000)
committerNicholas Clark <nick@ccl4.org>
Wed, 22 Sep 2021 06:53:03 +0000 (06:53 +0000)
commit2c205b5406a70a5753a289ca1b05dace7c12727a
treee36274b41e5697b3f951967a34258168d183569e
parent71e2181fdc1da7dfd599d69d45e604c493276c68
In Perl_gp_free() use PL_tmps_stack to avoid freeing glob entries immediately.

Typeglob assignment causes the current GP to be freed, and hence any package
variables it contains. As Perl's (data) stack is not reference counted, SVs
put on it are assumed to be owned by something else. For package variables,
this assumed owner is the typeglob. Hence if a single statement contains
both assignment to a typeglob and use of one of its variables, the
interpreter can read garbage (with all the usual explosive consequences).

This is yet another manifestation of "the stack is not reference counted",
and whilst troubling from a correctness perspective, can't be exploited
unless one can already run arbitrary code, in which case any attacker has
already won.

Whilst this problematic code doesn't turn up very often in real programs,
let alone hot paths, it is found quite often by researchers running
automated fuzzers. Previously these programs would trigger errors, that the
researchers would (legitimately) report, and then we would spend time
figuring out that the cause was "stack not reference counted" and so not a
dangerous security hole. This consumed a lot of researcher time, our time,
and prevents "interesting" security holes being uncovered.

Hence add code to use the temps stack to paper over the lack of stack
reference counting in this specific case. This should avoid a lot of time
spent on assessing and responding to legitimate but uninteresting security
reports, at a small cost in code complexity.
gv.c
t/op/gv.t