The is a bug in the PCRE library as reported to upstream <http://bugs.exim.org/show_bug.cgi?id=1546>: echo "a" | /tmp/pcre-8.36/pcregrep "((?=(?(?=(?(?=(?(?=())))*))))){2}" - ================================================================= ==29857==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x61000000fb94 at pc 0x7faf416f0dc6 bp 0x7fff9c91d3b0 sp 0x7fff9c91d3a8 READ of size 1 at 0x61000000fb94 thread T0 #0 0x7faf416f0dc5 in match /tmp/pcre-8.36/pcre_exec.c:1410:9 #1 0x7faf416dfe35 in match /tmp/pcre-8.36/pcre_exec.c:1538:7 #2 0x7faf416e46de in match /tmp/pcre-8.36/pcre_exec.c:1399:7 #3 0x7faf416dfe35 in match /tmp/pcre-8.36/pcre_exec.c:1538:7 #4 0x7faf416ee260 in match /tmp/pcre-8.36/pcre_exec.c:983:9 #5 0x7faf416dcd49 in pcre_exec /tmp/pcre-8.36/pcre_exec.c:6923:8 #6 0x4a4580 in match_patterns /tmp/pcre-8.36/pcregrep.c:1449:10 #7 0x4a13ca in pcregrep /tmp/pcre-8.36/pcregrep.c:1679:11 #8 0x4a3624 in grep_or_recurse /tmp/pcre-8.36/pcregrep.c:2122:10 #9 0x49efbf in main /tmp/pcre-8.36/pcregrep.c:3251:13 #10 0x7faf405b7ec4 in __libc_start_main /build/buildd/eglibc-2.19/csu/libc-start.c:287 #11 0x4172a6 in _start (/tmp/pcre-8.36/.libs/lt-pcregrep+0x4172a6) Upstream prepared a fix: --- pcre_exec.c (revision 1512) +++ pcre_exec.c (working copy) @@ -1404,8 +1404,11 @@ condition = TRUE; /* Advance ecode past the assertion to the start of the first branch, - but adjust it so that the general choosing code below works. */ - + but adjust it so that the general choosing code below works. If the + assertion has a quantifier that allows zero repeats we must skip over + the BRAZERO. This is a lunatic thing to do, but somebody did! */ + + if (*ecode == OP_BRAZERO) ecode++; ecode += GET(ecode, 1); while (*ecode == OP_ALT) ecode += GET(ecode, 1); ecode += 1 + LINK_SIZE - PRIV(OP_lengths)[condcode]; Which has not yet been pushed into the repository. Unfortunately, I cannot reproduce the bug. The patch will be applied after it emerges in the repository.
All Fedoras are affected. I can reproduce it now. Valgrind catches it too. The is visible in the upstream repository now.
pcre-8.35-8.fc21 has been submitted as an update for Fedora 21. https://admin.fedoraproject.org/updates/pcre-8.35-8.fc21
The fix requires extensive change which happens just after 8.33: commit e0f44ec0903da7ad9c56eec0a0e5c8b02ce6ccb3 Author: ph10 <ph10@2f5784b3-3f2a-0410-8824-cb99058d5e15> Date: Sun Oct 6 18:33:56 2013 +0000 Refactor named group handling for conditional tests. git-svn-id: svn://vcs.exim.org/pcre/code/trunk@1365 2f5784b3-3f2a-0410-8824-cb99058d5e15 12 files changed, 197 insertions(+), 228 deletions(-) So this fix will not applied to F19 and F20. Only F21 and newer will be fixed.
Turning this into Fedora security tracker
Package pcre-8.35-8.fc21: * should fix your issue, * was pushed to the Fedora 21 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing pcre-8.35-8.fc21' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-15573/pcre-8.35-8.fc21 then log in and leave karma (feedback).
pcre-8.33-8.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/pcre-8.33-8.fc20
pcre-8.32-12.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/pcre-8.32-12.fc19
pcre-8.35-8.fc21 has been pushed to the Fedora 21 stable repository. If problems still persist, please make note of it in this bug report.
pcre-8.32-12.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.
pcre-8.33-8.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.