It was found that there was no check for integer overflow in subroutine calls such as (?123) in pcre before 8.38, which allows remote attackers to cause a denial of service (integer overflow) or possibly have unspecified other impact via a crafted regular expression.
Created pcre tracking bugs for this issue: Affects: fedora-all [bug 1287647]
Created glib2 tracking bugs for this issue: Affects: fedora-all [bug 1287649]
Created mingw-pcre tracking bugs for this issue: Affects: fedora-all [bug 1287648] Affects: epel-7 [bug 1287650]
Corresponds to item 8 in http://vcs.pcre.org/pcre/code/trunk/ChangeLog?view=markup
Fixed in upstream with: commit 2de04da37bc9ec8f3ec74378839e5bfa7283ea1c Author: ph10 <ph10@2f5784b3-3f2a-0410-8824-cb99058d5e15> Date: Mon Jun 8 17:55:54 2015 +0000 Add integer overflow check to (?n) code. git-svn-id: svn://vcs.exim.org/pcre/code/trunk@1563 2f5784b3-3f2a-0410-8824- cb99058d5e15
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 2de04da37bc9ec8f3ec74378839e5bfa7283ea1c > Author: ph10 <ph10@2f5784b3-3f2a-0410-8824-cb99058d5e15> > Date: Mon Jun 8 17:55:54 2015 +0000 > > Add integer overflow check to (?n) code. Upstream commit link: http://vcs.pcre.org/pcre?view=revision&revision=1563
This is not a security issue. There is an integer overflow in the code that parses subroutine reference numbers. If such large reference number is provided, it may get parsed incorrectly, and may either reference "unexpected" sub-pattern, or refer to non-existent sub-pattern, leading to error as: Failed: reference to non-existent subpattern at offset 17 or Failed: internal error: previously-checked referenced subpattern not found at offset 18 So bad pattern may fail to compile or execute.