Skip to content
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

heap-buffer-overflow S_regmatch (regexec.c:7476) #15602

Closed
p5pRT opened this issue Sep 16, 2016 · 18 comments
Closed

heap-buffer-overflow S_regmatch (regexec.c:7476) #15602

p5pRT opened this issue Sep 16, 2016 · 18 comments

Comments

@p5pRT
Copy link

p5pRT commented Sep 16, 2016

Migrated from rt.perl.org#129281 (status was 'resolved')

Searchable as RT129281$

@p5pRT
Copy link
Author

p5pRT commented Aug 24, 2016

From @dcollinsn

Detected using AFL and libdislocator, but reproducible with valgrind and an uninstrumented perl.

The following regex causes a length-1 buffer to be allocated, but the second element of that buffer to be read, at two different points in S_regmatch. The buffer in question is reginfo->info_aux->poscache​:

perl -e '/0*()*(||0(?0))^*0^+|(?0)(?0)/'

The only visible output of this script is the message​:

But under debugging tools​:

%% VALGRIND %%

==40309== Invalid read of size 1
==40309== at 0xCB7E52​: S_regmatch (regexec.c​:7471)
==40309== by 0xCB7E52​: S_regtry (regexec.c​:3619)
==40309== by 0xD1A01D​: Perl_regexec_flags (regexec.c​:3486)
==40309== by 0x8FD147​: Perl_pp_match (pp_hot.c​:1836)
==40309== by 0x7E0833​: Perl_runops_debug (dump.c​:2234)
==40309== by 0x53A0D8​: S_run_body (perl.c​:2525)
==40309== by 0x53A0D8​: perl_run (perl.c​:2448)
==40309== by 0x429A47​: main (perlmain.c​:123)
==40309== Address 0x61bc8c1 is 0 bytes after a block of size 1 alloc'd
==40309== at 0x4C2A986​: calloc (vg_replace_malloc.c​:711)
==40309== by 0x7EFCAC​: Perl_safesyscalloc (util.c​:440)
==40309== by 0xCEAD24​: S_regmatch (regexec.c​:7453)
==40309== by 0xCEAD24​: S_regtry (regexec.c​:3619)
==40309== by 0xD1A01D​: Perl_regexec_flags (regexec.c​:3486)
==40309== by 0x8FD147​: Perl_pp_match (pp_hot.c​:1836)
==40309== by 0x7E0833​: Perl_runops_debug (dump.c​:2234)
==40309== by 0x53A0D8​: S_run_body (perl.c​:2525)
==40309== by 0x53A0D8​: perl_run (perl.c​:2448)
==40309== by 0x429A47​: main (perlmain.c​:123)
==40309==
==40309== Invalid read of size 1
==40309== at 0xCC153D​: S_regmatch (regexec.c​:7519)
==40309== by 0xCC153D​: S_regtry (regexec.c​:3619)
==40309== by 0xD1A01D​: Perl_regexec_flags (regexec.c​:3486)
==40309== by 0x8FD147​: Perl_pp_match (pp_hot.c​:1836)
==40309== by 0x7E0833​: Perl_runops_debug (dump.c​:2234)
==40309== by 0x53A0D8​: S_run_body (perl.c​:2525)
==40309== by 0x53A0D8​: perl_run (perl.c​:2448)
==40309== by 0x429A47​: main (perlmain.c​:123)
==40309== Address 0x61bc8c1 is 0 bytes after a block of size 1 alloc'd
==40309== at 0x4C2A986​: calloc (vg_replace_malloc.c​:711)
==40309== by 0x7EFCAC​: Perl_safesyscalloc (util.c​:440)
==40309== by 0xCEAD24​: S_regmatch (regexec.c​:7453)
==40309== by 0xCEAD24​: S_regtry (regexec.c​:3619)
==40309== by 0xD1A01D​: Perl_regexec_flags (regexec.c​:3486)
==40309== by 0x8FD147​: Perl_pp_match (pp_hot.c​:1836)
==40309== by 0x7E0833​: Perl_runops_debug (dump.c​:2234)
==40309== by 0x53A0D8​: S_run_body (perl.c​:2525)
==40309== by 0x53A0D8​: perl_run (perl.c​:2448)
==40309== by 0x429A47​: main (perlmain.c​:123)
==40309==

%% GDB SESSION %%

Starting program​: /home/dcollins/toolchain/perl/perl allcrash/f3i000025
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Breakpoint 3, S_regmatch (reginfo=0x7fffffffe070, startpos=0x80255f "",
  prog=0xac70a0) at regexec.c​:7442
%% Size determined here %%
7442 const SSize_t size = (reginfo->poscache_maxiter + 7)/8;
(gdb) p reginfo->poscache_maxiter
$2 = 3
(gdb) s
7443 regmatch_info_aux *const aux = reginfo->info_aux;
(gdb) p size
$3 = 1
(gdb) c
Continuing.

Breakpoint 2, S_regmatch (reginfo=0x7fffffffe070, startpos=0x80255f "",
  prog=0xac70a0) at regexec.c​:7453
%% Allocated here %%
7453 Newxz(aux->poscache, size, char);
(gdb) p size
$4 = 1
(gdb) n
7455 DEBUG_EXECUTE_r( Perl_re_printf( aTHX_
(gdb) p *aux
$5 = {info_aux_eval = 0x0, old_regmatch_state = 0xac2450,
  old_regmatch_slab = 0xac2450, poscache = 0xab4060 ""}
(gdb) c
Continuing.

Breakpoint 1, S_regmatch (reginfo=0x7fffffffe070, startpos=0x80255f "",
  prog=0xac70a0) at regexec.c​:7471
7471 if (reginfo->info_aux->poscache[offset] & mask) {
(gdb) p offset
$6 = 1
(gdb) l
7466 offset = (scan->flags & 0xf) - 1
7467 + (locinput - reginfo->strbeg)
7468 * (scan->flags>>4);
%% offset == 10 %%
7469 mask = 1 << (offset % 8);
7470 offset /= 8;
%% offset == 1 %%
%% Segfaults/reads past the end of the buffer here​: %%
7471 if (reginfo->info_aux->poscache[offset] & mask) {
7472 DEBUG_EXECUTE_r( Perl_re_exec_indentf( aTHX_ "whilem​: (cache) already tried at this position...\n",
7473 depth)
7474 );
7475 sayNO; /* cache records failure */
(gdb) p scan->flags
$7 = 59 ';'
(gdb) p reginfo->strbeg
$8 = 0x80255f ""
(gdb) p locinput
$9 = 0x80255f ""
(gdb) p offset
$10 = 1
(gdb) b regexec.c​:7519
Breakpoint 4 at 0x6e0132​: file regexec.c, line 7519.
(gdb) c
Continuing.

Breakpoint 4, S_regmatch (reginfo=0x7fffffffe070, startpos=0x80255f "",
  prog=0xac70a0) at regexec.c​:7519
7519 CACHEsayNO;
(gdb) l
7514
7515 case WHILEM_B_max_fail​: /* just failed to match B in a maximal match */
7516 cur_curlyx = ST.save_curlyx;
7517 cur_curlyx->u.curlyx.lastloc = ST.save_lastloc;
7518 cur_curlyx->u.curlyx.count--;
%% And again here​: %%
7519 CACHEsayNO;
7520 NOT_REACHED; /* NOTREACHED */
7521
7522 case WHILEM_A_min_fail​: /* just failed to match A in a minimal match */
7523 /* FALLTHROUGH */
(gdb)

--
Respectfully,
Dan Collins

@p5pRT
Copy link
Author

p5pRT commented Aug 24, 2016

From @cpansprout

On Tue Aug 23 19​:48​:57 2016, dcollinsn@​gmail.com wrote​:

Detected using AFL and libdislocator, but reproducible with valgrind
and an uninstrumented perl.

The following regex causes a length-1 buffer to be allocated, but the
second element of that buffer to be read, at two different points in
S_regmatch. The buffer in question is reginfo->info_aux->poscache​:

perl -e '/0*()*(||0(?0))^*0^+|(?0)(?0)/'

The only visible output of this script is the message​:

Infinite recursion in regex at -e line 1.

--

Father Chrysostomos

@p5pRT
Copy link
Author

p5pRT commented Aug 24, 2016

The RT System itself - Status changed from 'new' to 'open'

@p5pRT
Copy link
Author

p5pRT commented Sep 16, 2016

From @geeknik

v5.25.5 (v5.25.4-130-g7aa7bbc) + AFL + ASAN + libdislocator

perl -e '$0=/0(?0)|^*0(?0)|^*(^*())0|/'

==26041==ERROR​: AddressSanitizer​: heap-buffer-overflow on address
0x60200000e0f1 at pc 0x000000ba18bb bp 0x7ffe59ae8730 sp 0x7ffe59ae8728
READ of size 1 at 0x60200000e0f1 thread T0
  #0 0xba18ba in S_regmatch /root/perl/regexec.c​:7476​:11
  #1 0xb72ecc in S_regtry /root/perl/regexec.c​:3621​:14
  #2 0xb4b7dd in Perl_regexec_flags /root/perl/regexec.c​:3488​:7
  #3 0x8c2dd8 in Perl_pp_match /root/perl/pp_hot.c​:1836​:10
  #4 0x7f4583 in Perl_runops_debug /root/perl/dump.c​:2239​:23
  #5 0x5a11c6 in S_run_body /root/perl/perl.c​:2525​:2
  #6 0x5a11c6 in perl_run /root/perl/perl.c​:2448
  #7 0x4de5fd in main /root/perl/perlmain.c​:123​:9
  #8 0x7fdde284bb44 in __libc_start_main
/build/glibc-uPj9cH/glibc-2.19/csu/libc-start.c​:287
  #9 0x4de26c in _start (/root/perl/perl+0x4de26c)

0x60200000e0f1 is located 0 bytes to the right of 1-byte region
[0x60200000e0f0,0x60200000e0f1)
allocated by thread T0 here​:
  #0 0x4c0d40 in calloc (/root/perl/perl+0x4c0d40)
  #1 0x7f9401 in Perl_safesyscalloc /root/perl/util.c​:442​:18
  #2 0xb72ecc in S_regtry /root/perl/regexec.c​:3621​:14
  #3 0xb4b7dd in Perl_regexec_flags /root/perl/regexec.c​:3488​:7
  #4 0x8c2dd8 in Perl_pp_match /root/perl/pp_hot.c​:1836​:10
  #5 0x7f4583 in Perl_runops_debug /root/perl/dump.c​:2239​:23

SUMMARY​: AddressSanitizer​: heap-buffer-overflow /root/perl/regexec.c​:7476
S_regmatch
Shadow bytes around the buggy address​:
  0x0c047fff9bc0​: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c047fff9bd0​: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c047fff9be0​: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c047fff9bf0​: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c047fff9c00​: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
=>0x0c047fff9c10​: fa fa fa fa fa fa fa fa fa fa fa fa fa fa[01]fa
  0x0c047fff9c20​: fa fa fd fd fa fa fd fd fa fa fd fd fa fa fd fd
  0x0c047fff9c30​: fa fa fd fd fa fa fd fd fa fa fd fa fa fa fd fa
  0x0c047fff9c40​: fa fa fd fd fa fa fd fd fa fa 00 02 fa fa fd fd
  0x0c047fff9c50​: fa fa fd fd fa fa 02 fa fa fa 00 02 fa fa 00 07
  0x0c047fff9c60​: fa fa 00 fa fa fa 00 02 fa fa 05 fa fa fa 00 02
Shadow byte legend (one shadow byte represents 8 application bytes)​:
  Addressable​: 00
  Partially addressable​: 01 02 03 04 05 06 07
  Heap left redzone​: fa
  Heap right redzone​: fb
  Freed heap region​: fd
  Stack left redzone​: f1
  Stack mid redzone​: f2
  Stack right redzone​: f3
  Stack partial redzone​: f4
  Stack after return​: f5
  Stack use after scope​: f8
  Global redzone​: f9
  Global init order​: f6
  Poisoned by user​: f7
  Container overflow​: fc
  ASan internal​: fe
==26041==ABORTING

@p5pRT
Copy link
Author

p5pRT commented Oct 4, 2016

From @hvds

On Tue Aug 23 19​:48​:57 2016, dcollinsn@​gmail.com wrote​:

Detected using AFL and libdislocator, but reproducible with valgrind
and an uninstrumented perl.

The following regex causes a length-1 buffer to be allocated, but the
second element of that buffer to be read, at two different points in
S_regmatch. The buffer in question is reginfo->info_aux->poscache​:

perl -e '/0*()*(||0(?0))^*0^+|(?0)(?0)/'

The only visible output of this script is the message​:

But under debugging tools​:

%% VALGRIND %%

==40309== Invalid read of size 1
==40309== at 0xCB7E52​: S_regmatch (regexec.c​:7471)
==40309== by 0xCB7E52​: S_regtry (regexec.c​:3619)
==40309== by 0xD1A01D​: Perl_regexec_flags (regexec.c​:3486)
==40309== by 0x8FD147​: Perl_pp_match (pp_hot.c​:1836)
==40309== by 0x7E0833​: Perl_runops_debug (dump.c​:2234)
==40309== by 0x53A0D8​: S_run_body (perl.c​:2525)
==40309== by 0x53A0D8​: perl_run (perl.c​:2448)
==40309== by 0x429A47​: main (perlmain.c​:123)
[...]

The docs added by davem in 1cb95af say​:

  * The top 4 bits of scan->flags byte say how many different
  * relevant CURLLYX/WHILEM op pairs there are, while the
  * bottom 4-bits is the identifying index number of this
  * WHILEM.

.. and the code certainly appears to think that, using the top 4 bits to decide the size of poscache to malloc, and the bottom 4 bits to decide the index to look at. The invalid read occurs here because scan->flags == 0x3b, so something is violating that expectation; I don't yet know whether the expectation was wrong in the first place or something is abusing it.

Hugo

@p5pRT
Copy link
Author

p5pRT commented Oct 5, 2016

From @hvds

The prime cause here is that the handling of S_study_chunk() for CURLYX assumes it will be called only once for each node, but that is not the case. It attempts to use that assumption to record in the corresponding WHILEM for each CURLYX that it is the m'th of n such (whilem_c of whilem_seen); the n is later used to determine the size of poscache (the super-linear detection cache) while the m is used to determine the offset within poscache to look at.

When the CURLYX are visited more than once, whilem_c is incremented and stored in the WHILEM node each time, and will end up exceeding whilem_seen; the result is that we later address past the end of poscache.

You can see it in -Dr output; it should look like this​:
% ./perl -Dr -e 'qr{^*}' 2>&1 | grep WHILEM
  4​: WHILEM[1/1] (0)
%
.. but a GOSUB will reenter study_chunk to look at the same nodes and trigger the problem​:
% ./perl -Dr -e 'qr{^*(?0)}' 2>&1 | grep WHILEM
  4​: WHILEM[2/1] (0)
%

For the security concern​: the bit-offset in poscache is calculated as​:
  offset = (scan->flags & 0xf) - 1
  + (locinput - reginfo->strbeg) * (scan->flags >> 4);
.. where the first term '(scan->flags & 0xf)' is the wrong value described; as such the worst it can do is read and write 7 bits of the first byte following the allocated poscache, I'm not sure if that's a significant security concern or not.

The attached patch is a proof of concept​: I've no idea how to test this, and would like to be able to; I'm also not sure if the solution is the ideal one - study_chunk() does not seem like the ideal place to do this work, and scan->flags does not seem like the ideal place to store the information - but it is at least simple. (Adding just the new assert() suggests that no existing tests exercise this.)

Hugo

@p5pRT
Copy link
Author

p5pRT commented Oct 5, 2016

From @hvds

perl-129061

@p5pRT
Copy link
Author

p5pRT commented Oct 5, 2016

The RT System itself - Status changed from 'new' to 'open'

@p5pRT
Copy link
Author

p5pRT commented Oct 10, 2016

From @tonycoz

On Wed Oct 05 03​:34​:18 2016, hv wrote​:

The attached patch is a proof of concept​: I've no idea how to test
this, and would like to be able to; I'm also not sure if the solution
is the ideal one - study_chunk() does not seem like the ideal place to
do this work, and scan->flags does not seem like the ideal place to
store the information - but it is at least simple. (Adding just the
new assert() suggests that no existing tests exercise this.)

The usual way to test for this type of bug is to add a test that we expect to
fail under valgrind/ASAN.

So for this issue, something like the attached.

Without your fix, run with​:

  cd t
  PERL_RUNPERL_DEBUG="valgrind -q" ./perl harness re/pat.t

the test fails with​:

re/pat.t .. 800/800 # Failed test 800 - don't bump whilem_c too much at ./test.pl line 1058
# got "==15726== Invalid read of size 1\n==15726== at 0x5A74D0​: S_regmatch (regexec.c​:7477)\n==15726== by 0x59D181​: S_regtry (regexec.c​:3622)\n==15726== by 0x59CF31​: Perl_regexec_flags (regexec.c​:3489)\n==15726== by 0x50F98E​: Perl_pp_match (pp_hot.c​:1818)\n==15726== by 0x50891F​: Perl_runops_standard (run.c​:41)\n==15726== by 0x449769​: S_run_body (perl.c​:2526)\n==15726== by 0x449318​: perl_run (perl.c​:2449)\n==15726== by 0x41ECAD​: main (perlmain.c​:123)\n==15726== Address 0x5f86751 is 0 bytes after a block of size 1 alloc\'d\n==15726== at 0x4C2AD10​: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)\n==15726== by 0x4DDCD0​: Perl_safes
...

I'm not sure if that's a significant security concern or not.

As to whether this is a security issue, we're overflowing the end of the buffer, and if we expect regexps to be secure even when the regexps are untrusted strings*, this may at least be a denial of service, since it might crash the interpreter.

Depending on the system we might be overwriting the beginning of the next allocated block, maybe allowing a more useful attack.

Tony

* we don't require regexps to be untainted for example.

@p5pRT
Copy link
Author

p5pRT commented Oct 10, 2016

From @tonycoz

On Sun Oct 09 17​:35​:33 2016, tonyc wrote​:

So for this issue, something like the attached.

Really attached this time.

Tony

@p5pRT
Copy link
Author

p5pRT commented Oct 10, 2016

From @tonycoz

0001-perl-129281-test-for-buffer-overflow-issue.patch
From 46a40ab3bc159c4cb7a72fed5bded45a43400d5c Mon Sep 17 00:00:00 2001
From: Tony Cook <tony@develop-help.com>
Date: Mon, 10 Oct 2016 10:46:46 +1100
Subject: (perl #129281) test for buffer overflow issue

---
 t/re/pat.t | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/t/re/pat.t b/t/re/pat.t
index d0449e2..774fa91 100644
--- a/t/re/pat.t
+++ b/t/re/pat.t
@@ -23,7 +23,7 @@ BEGIN {
     skip_all('no re module') unless defined &DynaLoader::boot_DynaLoader;
     skip_all_without_unicode_tables();
 
-plan tests => 799;  # Update this when adding/deleting tests.
+plan tests => 800;  # Update this when adding/deleting tests.
 
 run_tests() unless caller;
 
@@ -1796,6 +1796,12 @@ EOP
             like("sS", qr/\N{}Ss|/i, "\N{} with empty branch alternation works");
         }
 
+        {
+            # [perl #129281] buffer write overflow, detected by ASAN, valgrind
+            local $::TODO = "whilem_c  bumped too much";
+            fresh_perl_is('/0(?0)|^*0(?0)|^*(^*())0|/', '', {}, "don't bump whilem_c too much");
+        }
+
 } # End of sub run_tests
 
 1;
-- 
2.1.4

@p5pRT
Copy link
Author

p5pRT commented Feb 4, 2017

From @iabyn

On Sun, Oct 09, 2016 at 05​:35​:33PM -0700, Tony Cook via RT wrote​:

On Wed Oct 05 03​:34​:18 2016, hv wrote​:

The attached patch is a proof of concept​: I've no idea how to test
this, and would like to be able to; I'm also not sure if the solution
is the ideal one - study_chunk() does not seem like the ideal place to
do this work, and scan->flags does not seem like the ideal place to
store the information - but it is at least simple. (Adding just the
new assert() suggests that no existing tests exercise this.)

The usual way to test for this type of bug is to add a test that we expect to
fail under valgrind/ASAN.

So for this issue, something like the attached.

Without your fix, run with​:

cd t
PERL_RUNPERL_DEBUG="valgrind -q" ./perl harness re/pat.t

the test fails with​:

re/pat.t .. 800/800 # Failed test 800 - don't bump whilem_c too much at ./test.pl line 1058
# got "==15726== Invalid read of size 1\n==15726== at 0x5A74D0​: S_regmatch (regexec.c​:7477)\n==15726== by 0x59D181​: S_regtry (regexec.c​:3622)\n==15726== by 0x59CF31​: Perl_regexec_flags (regexec.c​:3489)\n==15726== by 0x50F98E​: Perl_pp_match (pp_hot.c​:1818)\n==15726== by 0x50891F​: Perl_runops_standard (run.c​:41)\n==15726== by 0x449769​: S_run_body (perl.c​:2526)\n==15726== by 0x449318​: perl_run (perl.c​:2449)\n==15726== by 0x41ECAD​: main (perlmain.c​:123)\n==15726== Address 0x5f86751 is 0 bytes after a block of size 1 alloc\'d\n==15726== at 0x4C2AD10​: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)\n==15726== by 0x4DDCD0​: Perl_safes
...

I'm not sure if that's a significant security concern or not.

As to whether this is a security issue, we're overflowing the end of the
buffer, and if we expect regexps to be secure even when the regexps are
untrusted strings*, this may at least be a denial of service, since it
might crash the interpreter.

Depending on the system we might be overwriting the beginning of the
next allocated block, maybe allowing a more useful attack.

Tony

* we don't require regexps to be untainted for example.

I think there's already enough mischief you can you in perl by running
untrusted regexes that I don't think this is really a concern.

The worst it can do is set a bit in the bytes (or 2 bytes??) following the
buffer, or falsely fail the match if such a bit is set.

But these two things occur only if the WHILEM node with the dodgy index
is matching when the string position is within the last few chars of the
string. So the attacker would most likely need to control the string being
matched as well as the pattern.

All in all, I think it's a bit of a stretch and we should go ahead and
apply Hugo's fix and Tony's test.

I can't comment on the correctness of Hugo's fix, as the regex compiler
isn't an area of code I'm very familiar with - but I assume he knows what
he's doing :-).

--
Diplomacy is telling someone to go to hell in such a way that they'll
look forward to the trip

@p5pRT
Copy link
Author

p5pRT commented Feb 5, 2017

From @hvds

On Sat, 04 Feb 2017 09​:28​:17 -0800, davem wrote​:

All in all, I think it's a bit of a stretch and we should go ahead and
apply Hugo's fix and Tony's test.

Ok, unless someone says they want to do more review or raise other concerns, I'll aim to re-test and push on Monday.

I can't comment on the correctness of Hugo's fix, as the regex compiler
isn't an area of code I'm very familiar with - but I assume he knows
what he's doing :-).

How bold. :p

Hugo

@p5pRT
Copy link
Author

p5pRT commented Feb 6, 2017

From @hvds

Fix now pushed, along with Tony's test​:
42e9b60 [perl #129061] CURLYX nodes can be studied more than once
d2ba660 (perl #129281) test for buffer overflow issue

I've moved the ticket to the public queue, and will merge in [perl #129281].

Hugo

@p5pRT
Copy link
Author

p5pRT commented Feb 6, 2017

@hvds - Status changed from 'open' to 'pending release'

@p5pRT
Copy link
Author

p5pRT commented Feb 6, 2017

From @hvds

On Mon, 06 Feb 2017 07​:17​:31 -0800, hv wrote​:

[...] and will merge in [perl #129281].

Er, #129061 that is.

@p5pRT
Copy link
Author

p5pRT commented May 30, 2017

From @khwilliamson

Thank you for filing this report. You have helped make Perl better.

With the release today of Perl 5.26.0, this and 210 other issues have been
resolved.

Perl 5.26.0 may be downloaded via​:
https://metacpan.org/release/XSAWYERX/perl-5.26.0

If you find that the problem persists, feel free to reopen this ticket.

@p5pRT
Copy link
Author

p5pRT commented May 30, 2017

@khwilliamson - Status changed from 'pending release' to 'resolved'

@p5pRT p5pRT closed this as completed May 30, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant