A vulnerability was found in libpcre in PCRE before 8.43 allows a subject buffer over-read in JIT when UTF is disabled, and \X or \R has more than one fixed quantifier, a related issue to CVE-2019-20454.
References: https://bugs.gentoo.org/717920 https://www.pcre.org/original/changelog.txt
A vulnerability was found in libpcre in PCRE before 8.44 allows an integer overflow via a large number after a (?C substring.
References: https://bugs.gentoo.org/717920 https://www.pcre.org/original/changelog.txt
A stack-based buffer overflow flaw was found in PCRE. An attacker could use a crafted file that, when processed by PCRE, would crash the application using the PCRE library.
This issue only affects the PCRE version 8.40.
A stack-based buffer overflow flaw was found in PCRE. An attacker could use a crafted file that, when processed by PCRE, would crash the application using the PCRE library.
This issue only affects the PCRE version 8.40.
An invalid memory read flaw was found in PCRE. An attacker could use a crafted file that, when processed by PCRE, would crash the application using the PCRE library.
A vulnerability was found in pcre caused by trying to find a Unicode property for a code value greater than 0x10ffff, the Unicode maximum, when running in non-UTF mode (where character values can be up to 0xffffffff).
Upstream bug:
https://bugs.exim.org/showbug.cgi?id=2052
References:
https://blogs.gentoo.org/ago/2017/03/14/libpcre-invalid-memory-read-in-match-pcreexec-c/
Upstream patches (pcre):
https://vcs.pcre.org/pcre?view=revision&revision=1688
Upstream patches (pcre2):
https://vcs.pcre.org/pcre2?view=revision&revision=670
The compilebracketmatchingpath function in pcrejitcompile.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.
An invalid memory read flaw was found in PCRE. An attacker could use a crafted file that, when processed by PCRE, would crash the application using the PCRE library.
A stack-based buffer overflow flaw was found in PCRE. An attacker could use a crafted file that, when processed by PCRE, would crash the application using the PCRE library.
This issue only affects the PCRE version 8.40.
A stack-based buffer overflow flaw was found in PCRE. An attacker could use a crafted file that, when processed by PCRE, would crash the application using the PCRE library.
This issue only affects the PCRE version 8.40.
CVE-2006-7224 initially described several integer overflows in pcre, all described here: http://scary.beasts.org/security/CESA-2007-006.html
This id should be used to describe issue #2 in that advisory:
2) Uncharacterized crash researching item #1 above: Demo:
(?P<0>)(?P<1>)...fill in this sequence...(?P<3999>)
This does not trigger the integer overflow present in #1 above, but still crashes with a serious-looking memory error of some kind - possibly a buffer overflow.
Integer overflow in pcrecompile.c in Perl Compatible Regular Expressions (PCRE) before 6.2, as used in multiple products such as Python, Ethereal, and PHP, allows attackers to execute arbitrary code via quantifier values in regular expressions, which leads to a heap-based buffer overflow.
CVE-2006-7224 initially described several integer overflows in pcre, all described here: http://scary.beasts.org/security/CESA-2007-006.html
This id should be used to describe issue #1 in that advisory:
1) Integer overflow leading to buffer overflow.
pcrecompile: --- / Compute the size of data block needed and get it, either from malloc or externally provided function. /
size = length + sizeof(realpcre) + namecount (maxnamesize + 3); re = (realpcre )(pcremalloc)(size); ---
Unfortunately, a malicious regex can easily cause large "namecount" and "maxnamesize" such that this calculation overflows. Demo:
(?P)(?P<0>)(?P<1>)...fill in this sequence...(?P<4293>)
CVE-2006-7224 initially described several integer overflows in pcre, all described here: http://scary.beasts.org/security/CESA-2007-006.html
This id should be used to describe issue #2 in that advisory:
3) More possible integer overflow trouble.
pcrecompile: --- if (min == 0) { length++; if (max > 0) length += (max - 1) (duplength + 3 + 2LINKSIZE); } ... else { length += (min - 1) duplength; if (max > min) / Need this test as max=-1 means no limit / length += (max - min) (duplength + 3 + 2LINKSIZE) - (2 + 2LINKSIZE); } ---
In both these cases, I see no reason why a malicious regexp pattern couldn't cause an integer overflow by using large min / max / duplength values. This will really mess up the critical "length" value.
From pcre changelog, version 7.0:
4. Fixed a major bug that caused incorrect computation of the amount of memory required for a compiled pattern when options that changed within the pattern affected the logic of the preliminary scan that determines the length. The relevant options are -x, and -i in UTF-8 mode. The result was that the computed length was too small. The symptoms of this bug were either the PCRE error "internal error: code overflow" from pcrecompile(), or a glibc crash with a message such as "pcretest: free(): invalid next size (fast)". Examples of patterns that provoked this bug (shown in pcretest format) are:
/(?-x: )/x /(?x)(?-x: \s#\s)/ /((?i)[\x{c0}])/8 /(?i:[\x{c0}])/8
HOWEVER: Change 17 below makes this fix obsolete as the memory computation is now done differently.
Acknowledgements:
Red Hat would like to thank Ludwig Nussel for reporting this issue.
Heap-based buffer overflow in Perl-Compatible Regular Expression (PCRE) library before 7.3 allows context-dependent attackers to execute arbitrary code via a singleton Unicode sequence in a character class in a regex pattern, which is incorrectly optimized.
Multiple integer overflows in Perl-Compatible Regular Expression (PCRE) library before 7.3 allow context-dependent attackers to cause a denial of service (crash) or execute arbitrary code via unspecified escape (backslash) sequences.
Perl-Compatible Regular Expression (PCRE) library before 7.3 does not properly compute the length of (1) a \p sequence, (2) a \P sequence, or (3) a \P{x} sequence, which allows context-dependent attackers to cause a denial of service (infinite loop or crash) or execute arbitrary code.
Perl-Compatible Regular Expression (PCRE) library before 7.3 reads past the end of the string when searching for unmatched brackets and parentheses, which allows context-dependent attackers to cause a denial of service (crash), possibly involving forward references.
Perl-Compatible Regular Expression (PCRE) library before 7.3 allows context-dependent attackers to cause a denial of service (crash) and possibly execute arbitrary code via regex patterns containing unmatched "\Q\E" sequences with orphan "\E" codes.
Perl-Compatible Regular Expression (PCRE) library before 7.0 does not properly calculate sizes for unspecified "multiple forms of character class", which triggers a buffer overflow that allows context-dependent attackers to cause a denial of service (crash) and possibly execute arbitrary code.
Heap-based buffer overflow in pcrecompile.c in the Perl-Compatible Regular Expression (PCRE) library 7.7 allows context-dependent attackers to cause a denial of service (crash) or possibly execute arbitrary code via a regular expression that begins with an option and contains multiple branches.
pcrejitcompile.c in PCRE 8.35 does not properly use table jumps to optimize nested alternatives, which allows remote attackers to cause a denial of service (stack memory corruption) or possibly have unspecified other impact via a crafted string, as demonstrated by packets encountered by Suricata during use of a regular expression in an Emerging Threats Open ruleset.
From pcre changelog, version 7.0:
4. Fixed a major bug that caused incorrect computation of the amount of memory required for a compiled pattern when options that changed within the pattern affected the logic of the preliminary scan that determines the length. The relevant options are -x, and -i in UTF-8 mode. The result was that the computed length was too small. The symptoms of this bug were either the PCRE error "internal error: code overflow" from pcrecompile(), or a glibc crash with a message such as "pcretest: free(): invalid next size (fast)". Examples of patterns that provoked this bug (shown in pcretest format) are:
/(?-x: )/x /(?x)(?-x: \s#\s)/ /((?i)[\x{c0}])/8 /(?i:[\x{c0}])/8
HOWEVER: Change 17 below makes this fix obsolete as the memory computation is now done differently.
Acknowledgements:
Red Hat would like to thank Ludwig Nussel for reporting this issue.
From pcre changelog, version 6.7:
26. If a subpattern containing a named recursion or subroutine reference such as (?P>B) was quantified, for example (xxx(?P>B)){3}, the calculation of the space required for the compiled pattern went wrong and gave too small a value. Depending on the environment, this could lead to "Failed: internal error: code overflow at offset 49" or "glibc detected double free or corruption" errors.
Acknowledgements:
Red Hat would like to thank Ludwig Nussel for reporting this issue.
From pcre changelog, version 6.7:
18. A valid (though odd) pattern that looked like a POSIX character class but used an invalid character after [ (for example [[,abc,]]) caused pcrecompile() to give the error "Failed: internal error: code overflow" or in some cases to crash with a glibc free() error. This could even happen if the pattern terminated after [[ but there just happened to be a sequence of letters, a binary zero, and a closing ] in the memory that followed.
Acknowledgements:
Red Hat would like to thank Ludwig Nussel for reporting this issue.