pad.c | 4 3 + 1 - 0 !
1 file changed, 3 insertions(+), 1 deletion(-)

 don't leak the temp utf8 copy of namepv

Bug: https://rt.perl.org/Ticket/Display.html?id=123786
Bug-Debian: https://bugs.debian.org/822336

utils/h2ph.PL | 19 18 + 1 - 0 !
1 file changed, 18 insertions(+), 1 deletion(-)

 h2ph: correct handling of hex constants for the preamble

Previously they were treated as identifiers resulting in code
generated like C< &0xFFF >.

We also try to prevent compile-time warnings from large hex integers,
the user isn't responsible for the generated code, so we delay those
warnings to run-time.

(cherry picked from commit 3bea78d24634e630b610f59957e7a019205a67b2)

Bug-Debian: https://bugs.debian.org/822336

t/base/lex.t | 3 3 + 0 - 0 !
toke.c | 1 1 + 0 - 0 !
2 files changed, 4 insertions(+)

 fix crash with 0-5x-l{0}

perl-5.8.0-117-g6f33ba7, which added the XTERMORDORDOR hack, did not
change the leftbracket code to treat XTERMORDORDOR the same way as
XTERM, so -l {0} and getc {0} (among other ops) were treating {...} as
a block, rather than an anonymous hash.  This was not, however, being
turned into a real block with enter/leave ops to protect the stack,
so the nextstate op was corrupting the stack and possibly freeing mor-
tals in use.

This commit makes the leftbracket code check for XTERMORDORDOR and
treat it like XTERM, so that -l {0} once more creates an anonymous
hash.  There is really no way to get to that hash, though, so all I
can test for is the crash.

(cherry picked from commit 83a85f49e265a458a481a9dc402dd3bdd30ae457)

Bug: https://rt.perl.org/Ticket/Display.html?id=123711
Bug-Debian: https://bugs.debian.org/822336

util.c | 5 4 + 1 - 0 !
1 file changed, 4 insertions(+), 1 deletion(-)

 don't fatalize warnings during unwinding (#123398)

(cherry picked from commit 46b27d2f2c37f40dde845f9b4743975c69f2cc27)

Bug: https://rt.perl.org/Ticket/Display.html?id=123398
Bug-Debian: https://bugs.debian.org/822336

pp_sys.c | 2 1 + 1 - 0 !
1 file changed, 1 insertion(+), 1 deletion(-)

 =?utf-8?q?don=e2=80=99t=20treat=20setpgrp($nonzero)=20as=20setpgr?=
 =?UTF-8?q?p(1)?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

This was broken inadvertently by 92f2ac5f (5.15.3).

I really have no idea how to test this.  I only confirmed the bug and
its fix via a temporary warn statement in pp_setpgrp (obviously not
included in this commit).

(cherry picked from commit bae8cfc6926f9b04d8adac6a9ee6d563cc18263f)

Bug-Debian: https://bugs.debian.org/822336

cop.h | 12 11 + 1 - 0 !
t/op/sub.t | 52 51 + 1 - 0 !
2 files changed, 62 insertions(+), 2 deletions(-)

 rt #124156: death during unwinding causes crash

v5.19.3-139-g2537512 changed POPSUB and POPFORMAT so that they also
unwind the relevant portion of the scope stack. This (sensible) change
means that during exception handling, contexts and savestack frames are
popped in lock-step, rather than all the contexts being popped followed by
all the savestack contents.

However, LEAVE_SCOPE() is now called by POPSUB/FORMAT, which can trigger
destructors, tied method calls etc, which themselves may croak. The new
unwinding will see the old sub context still on the context stack and call
POPSUB on it again, leading to double frees etc.

At this late stage in code freeze, the least invasive change is to
use an unused bit in cx->blk_u16 to indicate that POPSUB has already
been called on this context frame.

Sometime later, this whole area of code really needs a thorough overhaul.
The main issue is that if cxstack_ix-- is done too early, then calling
destructors etc can overwrite the current context frame while we're still
using using it; if cxstack_ix-- is done too late, then that stack frame
can end up getting unwound twice.

(cherry picked from commit 1956db7ee60460e5b4a25c19fda4999666c8cbd1)

Bug: https://rt.perl.org/Ticket/Display.html?id=124156
Bug-Debian: https://bugs.debian.org/822336

gv.c | 2 1 + 1 - 0 !
1 file changed, 1 insertion(+), 1 deletion(-)

 fix crash with %::=(); j->${\"::"}

gv_stashpvn does not expect gv_fetchpv to return something that is
not a GV.  If someone has blown away the stash with %::=(), then the
$::{"main::"} entry no longer exists, but gv_fetchpv expects it to be
there.  This patch just makes this case fail somewhat gracefully
instead of crashing:

$  ./miniperl -e '%::=(); J->${\"::"}'
Can't locate object method "" via package "" (perhaps you forgot to load ""?) at -e line 1.

If someone does %::=(), nothing more reasonable should be expected.
At least it does not crash now.

(cherry picked from commit d2fcb1d6773910aef058d59681ff6ae649f68352)

Bug: https://rt.perl.org/Ticket/Display.html?id=125541
Bug-Debian: https://bugs.debian.org/822336

regcomp.c | 4 1 + 3 - 0 !
t/re/re_tests | 2 2 + 0 - 0 !
t/re/reg_mesg.t | 1 0 + 1 - 0 !
3 files changed, 3 insertions(+), 4 deletions(-)

 patch: [perl 125825] {n}+ possessive quantifier broken

I was unaware of this construct when I wrote the commit that broke it,
and there were no tests for it.  Now there are.

(cherry picked from commit 9a7bb2f73a8a1b561890191974201d576371e7f9)

[The perldelta update has been removed from this commit for the purposes
of the Debian patch import]

Bug: https://rt.perl.org/Ticket/Display.html?id=125825
Bug-Debian: https://bugs.debian.org/822336

t/op/lex.t | 10 9 + 1 - 0 !
toke.c | 4 3 + 1 - 0 !
2 files changed, 12 insertions(+), 2 deletions(-)

 fix /$a[/ parsing

The parser used to read more lines of input when parsing code interpo-
lated into quote-like operators, under some circumstance.  This would
result in code like this working, even though it should be a syn-
tax error:

s||${s/.*/|;
/s}Just another Perl hacker,
print

"${;s/.*/Just an";
other Perl hacker,
/s} die or return;
print

While this was harmless, other cases, like /$a[/<<a with no trailing
newline, would cause unexpected internal state that did not meet the
reasonable assumptions made by S_scan_heredoc, resulting in a crash.

The simplest fix is to modify the function that reads more input,
namely, lex_next_chunk, and prevent it from reading more lines of
input from inside a quote-like operator.  (The alternative would be to
modify all the calls to lex_next_chunk, and make them conditional.)
That breaks here-doc parsing for things like s//<<EOF/, but the
LEX_NO_TERM flag to lex_next_chunk is used only by the here-doc
parser, so lex_next_chunk can make an exception if it is set.

(cherry picked from commit e47d32dcd59a578274f445fac79e977d83055c8c)

Bug: https://rt.perl.org/Ticket/Display.html?id=123712
Bug-Debian: https://bugs.debian.org/822336

t/op/lex.t | 9 8 + 1 - 0 !
toke.c | 5 2 + 3 - 0 !
2 files changed, 10 insertions(+), 4 deletions(-)

 don't check sub_inwhat

PL_sublex_info.sub_inwhat (in the parser struct) is a temporary spot
to store the value of PL_lex_inwhat (also in the parser struct)
when a sub-lexing scope (for a quote-like operator) is entered.
PL_lex_inwhat is localised, and the value is copied from its temporary
spot (sub_inwhat) into PL_lex_inwhat.

The PL_sublex_info.sub_inwhat was not localised, but instead the value
was set to 0 when a sub-lexing scope was exited.  This value was being
used, in a couple of places, to determine whether we were inside a
quote-like operator.  But because the value is not localised, it can
be wrong when it is set to 0, if we have nested lexing scopes.

So this ends up crashing for the same reason described in e47d32dcd5:

echo -n '/$a[m||/<<a' | ./miniperl

perl-5.005_02-1816-g09bef84 added the first use of
PL_sublex_info.sub_inwhat to determine whether we are in a quote-like
operator.  (Later it got shifted around.)  I copied that in e47d32dcd5
(earlier today), because I assumed the logic was correct.  Other parts
of the code use PL_lex_inwhat, which is already localised, as I said,
and does not suffer this problem.

If we do not check PL_sublex_info.sub_inwhat to see if we are in
a quote-like construct, then we don't need to clear it on lexing
scope exit.

(cherry picked from commit d27f4b916ce5819f564bdd4a135137c457156333)

Bug: https://rt.perl.org/Ticket/Display.html?id=123712
Bug-Debian: https://bugs.debian.org/822336

t/op/lex.t | 19 15 + 4 - 0 !
toke.c | 3 2 + 1 - 0 !
2 files changed, 17 insertions(+), 5 deletions(-)

 fix hang with "@{"

Commit v5.21.8-320-ge47d32d stopped code interpolated into quote-like
operators from reading more lines of input, by making lex_next_chunk
ignore the open filehandle and return false.  That causes this block
under case 0 in yylex to loop:

	    if (!lex_next_chunk(fake_eof)) {
		CopLINE_dec(PL_curcop);
		s = PL_bufptr;
		TOKEN(';');	/* not infinite loop because rsfp is NULL now */
	    }

(rsfp is not null there.)  This commit makes it check for quote-like
operators above, in the same place where it checks whether the file is
open, to avoid falling through to this code that can loop.

This changes the syntax errors for a couple of cases recently added
to t/op/lex.t, though I think the error output is now more consis-
tent overall.

(cherry picked from commit 0f9d53bbcafba2b30e50a1ad22c7759be170e14a)

https://rt.perl.org/Ticket/Display.html?id=123893
Bug-Debian: https://bugs.debian.org/822336

op.h | 4 2 + 2 - 0 !
1 file changed, 2 insertions(+), 2 deletions(-)

 fix apidocs for op_type_is(_or_was) - arguments separated by |, not
 ,.

This was causing Devel::PPPort's tooling some grief.
(cherry picked from commit 5bfb0af0b8971c7f063804d149384ca17bfc0ae2)

Bug-Debian: https://bugs.debian.org/822336

pod/perlpodspec.pod | 12 9 + 3 - 0 !
1 file changed, 9 insertions(+), 3 deletions(-)

 perlpodspec: corrections/adds to detecting =encoding

C0 and C1 are not legal UTF-8 start bytes.  utf8::decode() is a more
accurate way of determining UTF-8.
(cherry picked from commit 9a5b9407081290adfb965563aed854ccd8560db6)

Bug-Debian: https://bugs.debian.org/822336

sv.h | 11 8 + 3 - 0 !
1 file changed, 8 insertions(+), 3 deletions(-)

 improve svpv_set's docs, it really shouldn't be public api

Someone else in the perl community wrote XS code using SvPV_set instead
of sv_setpvn and couldn't figure out why he was getting
heap corruption/failed asserts/SEGVs/etc. Improve the docs to basically say
never use this.
(cherry picked from commit f2979eac0a03fcba1cd431ef3d46f697176ebcc8)

Bug-Debian: https://bugs.debian.org/822336

pod/perlunicook.pod | 2 1 + 1 - 0 !
1 file changed, 1 insertion(+), 1 deletion(-)

 fix warning message regarding "use autodie" and "use open".

(cherry picked from commit 730d89736d0ae5dfc7580108c451efe91b5102fc)

Bug-Debian: https://bugs.debian.org/822336

pod/perlunicook.pod | 3 2 + 1 - 0 !
1 file changed, 2 insertions(+), 1 deletion(-)

 perlunicook: note that autodie >= 2.26 should be okay with "use
 open".

(cherry picked from commit 2a403855670ae8592c5a3ca4396e6e909a4fc593)

Bug-Debian: https://bugs.debian.org/822336

pod/perlclib.pod | 2 1 + 1 - 0 !
1 file changed, 1 insertion(+), 1 deletion(-)

 fix setenv() replacement documentation in perlclib

my_putenv doesn't exist, the function is called my_setenv

(cherry picked from commit 7ad03f5069e771fe44e92b694a23f10354c548d1)

Bug-Debian: https://bugs.debian.org/822336

pod/perlhacktips.pod | 33 33 + 0 - 0 !
1 file changed, 33 insertions(+)

 perlhacktips: add caution about clib ptr returns to static memory

(cherry picked from commit 38f18a308b948c6eaf187519a16d060e1ec7cc20)

Bug-Debian: https://bugs.debian.org/822336

pod/perlunicook.pod | 4 2 + 2 - 0 !
1 file changed, 2 insertions(+), 2 deletions(-)

 fix minor code typos in perlunicook

(cherry picked from commit 7b237c8f3da9b9cd57a5cbd035ff4d3e70dcbb7b)

Bug-Debian: https://bugs.debian.org/822336

pod/perlguts.pod | 38 28 + 10 - 0 !
1 file changed, 28 insertions(+), 10 deletions(-)

 update ook example in perlguts

It was not just the COW changes that needed to be accounted for, but
also the change in the storage of the offset.  The latter changed hap-
pened in 5.12, I think.

(cherry picked from commit f942a0dfa923e36f91c00b44e21563cd50dc750b)

Bug: https://rt.perl.org/Ticket/Display.html?id=122322
Bug-Debian: https://bugs.debian.org/822336

pod/perlfunc.pod | 8 6 + 2 - 0 !
1 file changed, 6 insertions(+), 2 deletions(-)

 perlfunc: mention that study() is currently a noop

(cherry picked from commit d8c1af4e0d4774b60bd59dc0039c7e101f292a4a)

Bug-Debian: https://bugs.debian.org/822336

cpan/Archive-Tar/bin/ptar | 1 1 + 0 - 0 !
cpan/Archive-Tar/bin/ptardiff | 1 1 + 0 - 0 !
cpan/Archive-Tar/bin/ptargrep | 1 1 + 0 - 0 !
cpan/CPAN/scripts/cpan | 1 1 + 0 - 0 !
cpan/Digest-SHA/shasum | 1 1 + 0 - 0 !
cpan/Encode/bin/enc2xs | 1 1 + 0 - 0 !
cpan/Encode/bin/piconv | 1 1 + 0 - 0 !
cpan/Encode/bin/ucmlint | 1 1 + 0 - 0 !
cpan/Encode/bin/unidump | 1 1 + 0 - 0 !
cpan/ExtUtils-MakeMaker/bin/instmodsh | 1 1 + 0 - 0 !
cpan/IO-Compress/bin/zipdetails | 1 1 + 0 - 0 !
cpan/JSON-PP/bin/json_pp | 1 1 + 0 - 0 !
cpan/Test-Harness/bin/prove | 1 1 + 0 - 0 !
dist/ExtUtils-ParseXS/lib/ExtUtils/xsubpp | 1 1 + 0 - 0 !
dist/Module-CoreList/corelist | 1 1 + 0 - 0 !
ext/Pod-Html/bin/pod2html | 1 1 + 0 - 0 !
utils/c2ph.PL | 1 1 + 0 - 0 !
utils/h2ph.PL | 2 2 + 0 - 0 !
utils/h2xs.PL | 2 2 + 0 - 0 !
utils/libnetcfg.PL | 1 1 + 0 - 0 !
utils/perlbug.PL | 1 1 + 0 - 0 !
utils/perldoc.PL | 5 4 + 1 - 0 !
utils/perlivp.PL | 2 2 + 0 - 0 !
utils/splain.PL | 6 6 + 0 - 0 !
24 files changed, 35 insertions(+), 1 deletion(-)

 (perl #127834) remove . from the end of @inc if complex modules are
 loaded

While currently Encode and Storable are know to attempt to load modules
not included in the core, updates to other modules may lead to those
also attempting to load new modules, so be safe and remove . for those
as well.

(Backported to 5.20.2 by Niko Tyni <ntyni@debian.org>)

lib/perl5db.pl | 10 8 + 2 - 0 !
1 file changed, 8 insertions(+), 2 deletions(-)

 perl5db.pl: ensure padwalker is loaded from standard paths

cpan/Test/lib/Test.pm | 7 6 + 1 - 0 !
dist/I18N-LangTags/lib/I18N/LangTags/Detect.pm | 2 2 + 0 - 0 !
dist/IO/IO.pm | 2 2 + 0 - 0 !
dist/Locale-Maketext/lib/Locale/Maketext.pm | 2 2 + 0 - 0 !
dist/Net-Ping/lib/Net/Ping.pm | 6 5 + 1 - 0 !
dist/PathTools/Cwd.pm | 5 4 + 1 - 0 !
dist/PathTools/lib/File/Spec/Cygwin.pm | 6 5 + 1 - 0 !
dist/PathTools/lib/File/Spec/VMS.pm | 5 4 + 1 - 0 !
dist/PathTools/lib/File/Spec/Win32.pm | 6 5 + 1 - 0 !
dist/Storable/Storable.pm | 8 7 + 1 - 0 !
dist/base/lib/base.pm | 6 5 + 1 - 0 !
11 files changed, 47 insertions(+), 8 deletions(-)

 dist/: remove . from @inc when loading optional modules

(Backported to 5.20.2 by Niko Tyni <ntyni@debian.org>)

cpan/CPAN/lib/App/Cpan.pm | 21 16 + 5 - 0 !
cpan/CPAN/lib/CPAN.pm | 4 4 + 0 - 0 !
cpan/Digest/Digest.pm | 6 5 + 1 - 0 !
cpan/Encode/Encode.pm | 2 2 + 0 - 0 !
cpan/File-Fetch/lib/File/Fetch.pm | 10 10 + 0 - 0 !
cpan/HTTP-Tiny/lib/HTTP/Tiny.pm | 2 2 + 0 - 0 !
cpan/IO-Compress/lib/IO/Uncompress/AnyUncompress.pm | 2 2 + 0 - 0 !
cpan/IPC-Cmd/lib/IPC/Cmd.pm | 4 4 + 0 - 0 !
cpan/Locale-Maketext-Simple/lib/Locale/Maketext/Simple.pm | 7 6 + 1 - 0 !
cpan/Memoize/Memoize.pm | 6 5 + 1 - 0 !
cpan/Pod-Perldoc/lib/Pod/Perldoc.pm | 5 5 + 0 - 0 !
cpan/Sys-Syslog/Syslog.pm | 2 2 + 0 - 0 !
cpan/libnet/Net/Config.pm | 7 6 + 1 - 0 !
dist/ExtUtils-Command/lib/ExtUtils/Command.pm | 5 4 + 1 - 0 !
dist/bignum/lib/bigint.pm | 2 2 + 0 - 0 !
dist/bignum/lib/bignum.pm | 2 2 + 0 - 0 !
dist/bignum/lib/bigrat.pm | 2 2 + 0 - 0 !
17 files changed, 79 insertions(+), 10 deletions(-)

 cpan/: remove . from @inc when loading optional modules

This was originally against maint-5.24 where bignum is in cpan/, but
in maint-5.22 it was in dist/

(Backported to 5.20.2 by Niko Tyni <ntyni@debian.org>)

t/porting/customized.dat | 2 1 + 1 - 0 !
1 file changed, 1 insertion(+), 1 deletion(-)

 update customized.dat for cpan/encode/encode.pm

Makefile.SH | 2 1 + 1 - 0 !
Porting/pod_rules.pl | 2 1 + 1 - 0 !
TestInit.pm | 2 1 + 1 - 0 !
lib/strict.t | 2 1 + 1 - 0 !
lib/warnings.t | 2 1 + 1 - 0 !
makedef.pl | 2 1 + 1 - 0 !
regen.pl | 2 1 + 1 - 0 !
regen/genpacksizetables.pl | 2 1 + 1 - 0 !
regen/mg_vtable.pl | 2 1 + 1 - 0 !
t/comp/line_debug.t | 2 2 + 0 - 0 !
t/lib/warnings/op | 1 1 + 0 - 0 !
t/op/goto.t | 2 1 + 1 - 0 !
t/porting/regen.t | 2 1 + 1 - 0 !
t/re/pat.t | 2 1 + 1 - 0 !
t/run/switches.t | 6 3 + 3 - 0 !
t/test.pl | 3 2 + 1 - 0 !
16 files changed, 20 insertions(+), 16 deletions(-)

 patch unit tests to explicitly insert "." into @inc when needed.

(Backported to Debian 5.20 by Niko Tyni <ntyni@debian.org>)

Bug: https://rt.perl.org/Public/Bug/Display.html?id=127810

cpan/ExtUtils-MakeMaker/lib/ExtUtils/MM_Unix.pm | 4 2 + 2 - 0 !
cpan/ExtUtils-MakeMaker/lib/ExtUtils/MakeMaker.pm | 5 5 + 0 - 0 !
2 files changed, 7 insertions(+), 2 deletions(-)

 add perl_use_unsafe_inc support to eu::mm for fortify_inc support.

This change allows the majority of Perl modules that cannot build/test/install
without . in INC to be able to do so, while maintaining a safer perl under
normal use.

(Backported by Debian 5.20 by Niko Tyni <ntyni@debian.org>)

Bug: https://rt.perl.org/Public/Bug/Display.html?id=127810

cpan/CPAN/scripts/cpan | 5 5 + 0 - 0 !
1 file changed, 5 insertions(+)

 set perl_use_unsafe_inc for cpan usage

This change allows the majority of Perl modules to build/test/install from the
cpan client without having to modify them.

Bug: https://rt.perl.org/Public/Bug/Display.html?id=127810

cpan/Module-Build/lib/Module/Build/Base.pm | 2 2 + 0 - 0 !
1 file changed, 2 insertions(+)

 make module::build set perl_use_unsafe_inc

perl.c | 5 5 + 0 - 0 !
pod/perlrun.pod | 5 5 + 0 - 0 !
2 files changed, 10 insertions(+)

 look for sitecustomize.pl in /etc/perl rather than sitelib on debian
 systems

Debian uses this sitecustomize.pl as a transition mechanism for removing
the current working directory (".") from @INC by default while leaving
the local administrator a temporary means of re-adding it back.

This mechanism is expected to be removed after one Debian stable release.

dist/XSLoader/XSLoader_pm.PL | 25 25 + 0 - 0 !
dist/XSLoader/t/XSLoader.t | 27 26 + 1 - 0 !
2 files changed, 51 insertions(+), 1 deletion(-)

 =?utf-8?q?don=e2=80=99t=20let=20xsloader=20load=20relative=20path?=
 =?UTF-8?q?s?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

[rt.cpan.org #115808]

The logic in XSLoader for determining the library goes like this:

    my $c = () = split(/::/,$caller,-1);
    $modlibname =~ s,[\\/][^\\/]+$,, while $c--;    # Q&D basename
    my $file = "$modlibname/auto/$modpname/$modfname.bundle";

(That last line varies by platform.)

$caller is the calling package.  $modlibname is the calling file.  It
removes as many path segments from $modlibname as there are segments
in $caller.  So if you have Foo/Bar/XS.pm calling XSLoader from the
Foo::Bar package, the $modlibname will end up containing the path in
@INC where XS.pm was found, followed by "/Foo".  Usually the fallback
to Dynaloader::bootstrap_inherit, which does an @INC search, makes
things Just Work.

But if our hypothetical Foo/Bar/XS.pm actually calls
XSLoader::load from inside a string eval, then path ends up being
"(eval 1)/auto/Foo/Bar/Bar.bundle".

So if someone creates a directory named (eval 1) with a naughty
binary file in it, it will be loaded if a script using Foo::Bar is run
in the parent directory.

This commit makes XSLoader fall back to Dynaloaders @INC search if
the calling file has a relative path that is not found in @INC.

[Backported to 5.20 by Dominic Hargreaves]

Bug-Debian: https://bugs.debian.org/829578
Bug: https://rt.cpan.org/Ticket/Display.html?id=115808

cpan/File-Path/lib/File/Path.pm | 20 14 + 6 - 0 !
cpan/File-Path/t/Path.t | 24 17 + 7 - 0 !
2 files changed, 31 insertions(+), 13 deletions(-)

 prevent directory chmod race attack.

CVE-2017-6512 is a race condition attack where the chmod() of directories
that cannot be entered is misused to change the permissions on other
files or directories on the system. This has been corrected by limiting
the directory-permission loosening logic to systems where fchmod() is
supported.

[Backported to File-Path 2.09 / perl 5.20 by Dominic Hargreaves for Debian.]

Bug: https://rt.cpan.org/Public/Bug/Display.html?id=121951
Bug-Debian: https://bugs.debian.org/863870

dist/ExtUtils-Command/t/eu_command.t | 13 7 + 6 - 0 !
1 file changed, 7 insertions(+), 6 deletions(-)

 [patch] correct the order of tests of chmod(). (#294)

Per code review by haarg, the order of tests was wrong in the first place.
Hence, correctly re-ordering them is a better repair than changing one test's
description.

For: https://github.com/Perl-Toolchain-Gang/ExtUtils-MakeMaker/pull/294

[Debian note: this is a prerequisite for the CVE-2017-6512 fix in
File-Path, and was backported by Dominic Hargreaves]

Bug: https://github.com/Perl-Toolchain-Gang/ExtUtils-MakeMaker/pull/294

t/porting/customized.dat | 3 3 + 0 - 0 !
1 file changed, 3 insertions(+)

 update customized.dat for file-path changes

dist/base/lib/base.pm | 6 1 + 5 - 0 !
1 file changed, 1 insertion(+), 5 deletions(-)

 revert base.pm no-dot-in-inc fixes to make way for a better version

MANIFEST | 1 1 + 0 - 0 !
dist/base/lib/base.pm | 55 53 + 2 - 0 !
dist/base/t/incdot.t | 55 55 + 0 - 0 !
dist/base/t/lib/BaseIncMandatory.pm | 9 9 + 0 - 0 !
dist/base/t/lib/BaseIncOptional.pm | 13 13 + 0 - 0 !
5 files changed, 131 insertions(+), 2 deletions(-)

 limit dotless-inc effect on base.pm with guard:

This introduces a more refined and accurate solution for removing
'.' from @INC while reducing the false positives.

The following explanation is roughly what is avaiable in the code
comments. If you stumble upon this and feel like the commit message
or the comments are not helpful enough, please introduce another
commit that adds more explanation or improve the code comments
(or both).

Using

    if ($INC[-1] eq '.' && %{"$base\::"})

We decide that:

The package already exists   => this an optional load
And: there is a dot at the end of @INC  => we want to hide it
However: we only want to hide it during our *own* require()
(i.e. without affecting nested require()s).

So we add a hook to @INC whose job is to hide the dot, but which
first checks checks the callstack depth, because within nested
require()s the callstack is deeper.

Since CORE::GLOBAL::require makes it unknowable in advance what
the exact relevant callstack depth will be, we have to record it
inside a hook. So we put another hook just for that at the front
of @INC, where it's guaranteed to run -- immediately.

The dot-hiding hook does its job by sitting directly in front of
the dot and removing itself from @INC when reached. This causes
the dot to move up one index in @INC, causing the loop inside
pp_require() to skip it.

Loaded coded may disturb this precise arrangement, but that's OK
because the hook is inert by that time. It is only active during
the top-level require(), when @INC is in our control. The only
possible gotcha is if other hooks already in @INC modify @INC in
some way during that initial require().

Note that this jiggery hookery works just fine recursively: if
a module loaded via base.pm uses base.pm itself, there will be
one pair of hooks in @INC per base::import call frame, but the

regcomp.c | 1 1 + 0 - 0 !
1 file changed, 1 insertion(+)

 regcomp [perl #131582]

regcomp.c | 4 3 + 1 - 0 !
1 file changed, 3 insertions(+), 1 deletion(-)

 patch: [perl #131598]

The cause of this is that the vFAIL macro uses RExC_parse, and that
variable has just been changed in preparation for code after the vFAIL.
The solution is to not change RExC_parse until after the vFAIL.

This is a case where the macro hides stuff that can bite you.

(backported to 5.20 by Niko Tyni)

regcomp.c | 21 12 + 9 - 0 !
1 file changed, 12 insertions(+), 9 deletions(-)

 regcomp: fix out of bound reads

This is a backport of 730480ce9e3e0103efa8f551281a62b39f573b1a
to the 5.20 series, fixing further out of bound reads related
to CVE-2017-12883.

pp_pack.c | 25 21 + 4 - 0 !
t/op/pack.t | 24 23 + 1 - 0 !
2 files changed, 44 insertions(+), 5 deletions(-)

 (perl #131844) fix various space calculation issues in pp_pack.c

- for the originally reported case, if the start/cur pointer is in the
  top 75% of the address space the add (cur) + glen addition would
  overflow, resulting in the condition failing incorrectly.

- the addition of the existing space used to the space needed could
  overflow, resulting in too small an allocation and a buffer overflow.

- the scaling for UTF8 could overflow.

- the multiply to calculate the space needed for many items could
  overflow.

For the first case, do a space calculation without making new pointers.

For the other cases, detect the overflow and croak if there's an
overflow.

Originally this used Size_t_MAX as the maximum size of a memory
allocation, but for -DDEBUGGING builds realloc() throws a panic for
allocations over half the address space in size, changing the error
reported for the allocation.

For non-DEBUGGING builds the Size_t_MAX limit has the small chance
of finding a system that has 3GB of contiguous space available, and
allocating that space, which could be a denial of servce in some cases.

Unfortunately changing the limit to half the address space means that
the exact case with the original issue can no longer occur, so the
test is no longer testing against the address + length issue that
caused the original problem, since the allocation is failing earlier.

One option would be to change the test so the size request by pack is
just under 2GB, but this has a higher (but still low) probability that
the system has the address space available, and will actually try to
allocate the memory, so let's not do that.

cpan/Archive-Tar/lib/Archive/Tar.pm | 14 14 + 0 - 0 !
t/porting/customized.dat | 1 1 + 0 - 0 !
2 files changed, 15 insertions(+)

 remove existing files before overwriting them

Archive should extract only the latest same-named entry.
Extracted regular file should not be writtent into existing block
device (or any other one).

[with t/porting/customized.dat updated for Debian]

Signed-off-by: Chris 'BinGOs' Williams <chris@bingosnet.co.uk>
Bug: https://rt.cpan.org/Ticket/Display.html?id=125523
Bug-Debian: https://bugs.debian.org/900834