It was discovered that PCRE before 8.38 mishandles the interaction of lookbehind assertions and mutually recursive subpatterns could provoke a buffer overflow, allowing remote attackers to cause a denial of service (buffer overflow) or possibly have unspecified other impact via a crafted regular expression.
Created pcre tracking bugs for this issue: Affects: fedora-all [bug 1287639]
Created glib2 tracking bugs for this issue: Affects: fedora-all [bug 1287641]
Created mingw-pcre tracking bugs for this issue: Affects: fedora-all [bug 1287640] Affects: epel-7 [bug 1287642]
Corresponds to item 6 in http://vcs.pcre.org/pcre/code/trunk/ChangeLog?view=markup
Fixed in upstream with: commit 9f2cf82ed9380bb4a726250833d6a0d295be8747 Author: ph10 <ph10@2f5784b3-3f2a-0410-8824-cb99058d5e15> Date: Tue May 19 16:02:06 2015 +0000 Fix buffer overflow for lookbehind within mutually recursive subroutines. git-svn-id: svn://vcs.exim.org/pcre/code/trunk@1560 2f5784b3-3f2a-0410-8824-cb99058d5e15
Reproducer is passing ".*?\h.+.\.+\R*?\xd(?i)(?=!(?=b`b`b`\`b\xa9b!)`\a`bbbbbbbbbbbbb`bbbbbbbbbbbb*R\x85bbbbbbb\C?{((?2)(?))((\H){8(?<=(?1){29}\xa8bbbb\x16\xd\xc6^($(?<! )(\xa9H4){4}h}1)B))\x15')" expression to pcretest under valgrind.
pcre-8.38-1.fc22 has been pushed to the Fedora 22 stable repository. If problems still persist, please make note of it in this bug report.
(In reply to Petr Pisar from comment #5) > Fixed in upstream with: > > commit 9f2cf82ed9380bb4a726250833d6a0d295be8747 > Author: ph10 <ph10@2f5784b3-3f2a-0410-8824-cb99058d5e15> > Date: Tue May 19 16:02:06 2015 +0000 > > Fix buffer overflow for lookbehind within mutually recursive subroutines. Upstream SVN commit link is: http://vcs.pcre.org/pcre?view=revision&revision=1560
The issue corrected in r1560 seems to date back to very old PCRE versions. Version 3.9 (in Red Hat Enterprise Linux 3) was not affected, while version 4.5 (in Red Hat Enterprise Linux 4) already contains the bug. I've not tried to pin point specific version. Upstream SVN also only seems to have code as of version 6.0. I could reduce the pattern noted in comment 6 down to: /(?=((?2))((x){(?<=(?1){29}\xaaXABCDE(x(?<!)(\xaaXA){4}A}B)C)))/ This pattern triggers a valgrind detected out of bounds read in PCRE versions 8.34 - 8.37. Upstream r1379 seems to be what makes this issue detectable by valgrind, as that commits adds new opcodes and consequently changes which code paths are used when compiling the above pattern. Another symptom of this bug is an error as this: Failed: internal error: unknown opcode in find_fixedlength() at offset 62 This has limited out of bounds read impact.
This issue has been addressed in the following products: Red Hat Enterprise Linux 7 Via RHSA-2016:1025 https://rhn.redhat.com/errata/RHSA-2016-1025.html
This issue has been addressed in the following products: Red Hat Software Collections for Red Hat Enterprise Linux 7.1 EUS Red Hat Software Collections for Red Hat Enterprise Linux 7.2 EUS Red Hat Software Collections for Red Hat Enterprise Linux 7 Red Hat Software Collections for Red Hat Enterprise Linux 6.6 EUS Red Hat Software Collections for Red Hat Enterprise Linux 6 Red Hat Software Collections for Red Hat Enterprise Linux 6.7 EUS Via RHSA-2016:1132 https://access.redhat.com/errata/RHSA-2016:1132
This issue has been addressed in the following products: Red Hat Software Collections for Red Hat Enterprise Linux 6 Red Hat Software Collections for Red Hat Enterprise Linux 6.7 EUS Red Hat Software Collections for Red Hat Enterprise Linux 7 Red Hat Software Collections for Red Hat Enterprise Linux 7.2 EUS Red Hat Software Collections for Red Hat Enterprise Linux 7.3 EUS Via RHSA-2016:2750 https://rhn.redhat.com/errata/RHSA-2016-2750.html