The compile_bracket_matchingpath function in pcre_jit_compile.c in PCRE through 8.x before revision 1680 (e.g., the PHP 7.1.1 bundled version) allows remote attackers to cause a denial of service (out-of-bounds read and application crash) via a crafted regular expression. This seems to be fixed in the 8.40 release. https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-6004 https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2017-6004 https://bugs.exim.org/show_bug.cgi?id=2035
Upstream patch: https://vcs.pcre.org/pcre/code/trunk/pcre_jit_compile.c?r1=1676&r2=1680&view=patch This is _not_ included in v8.40 release. @ Maintainer(s): Could you please rev bump and cherry-pick the patch (I attached a complete patch including updated tests)? You may also want to cherry-pick https://vcs.pcre.org/pcre/code/trunk/pcregrep.c?r1=1678&r2=1679&view=patch which fixes a bug/incomplete fix for > 1. Using -o with -M in pcregrep could cause unnecessary repeated output when > the match extended over a line boundary.
Created attachment 464034 [details, diff] Upstream fix for CVE-2017-6004 with updated tests
libpcre-8.40-r1 in the tree now w/the two fixes: https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=ef1e0f46ae56483d3b5695108e684a887bab4d33 should be fine for stable
amd64 stable
ppc stable
ppc64 stable
Stable for HPPA.
arm stable.
arm64 stable.
alpha/ia64 stable
x86 stable
We can not wait any longer on sparc. Please stabilize, we are going to work on releasing the GLSA.
sparc stable. Maintainer(s), please cleanup.
Cleanup PR: https://github.com/gentoo/gentoo/pull/4848
This issue was resolved and addressed in GLSA 201706-11 at https://security.gentoo.org/glsa/201706-11 by GLSA coordinator Kristian Fiskerstrand (K_F).
