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.

A flaw was found in libpcre. A buffer overread in JIT mode when \X is used in non-UTF mode may cause application crash and denial of service. The flaw is in function doextuninoutf() in pcre2jitcompile.c, which uses the macro GETCHARINC to read a character. However, in case there is an invalid UTF character the value read is too big, which causes an out-of-bounds read in the next statement, while executing macro UCDGRAPHBREAK.

References:

https://bugs.exim.org/showbug.cgi?id=2421 https://bugzilla.redhat.com/showbug.cgi?id=1734468

Upstream patch:

http://git.php.net/?p=php-src.git;a=commitdiff;h=8947fd9e9fdce87cd6c59817b1db58e789538fe9

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.

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.

An out-of-bounds read vulnerability was discovered in the PCRE2 library in the compilexclassmatchingpath() function of the pcre2jitcompile.c file. This involves a unicode property matching issue in JIT-compiled regular expressions. The issue occurs because the character was not fully read in case-less matching within JIT.

The PCRE2 library is a set of C functions that implement regular expression pattern matching. In version 10.45, a heap-buffer-overflow read vulnerability exists in the PCRE2 regular expression matching engine, specifically within the handling of the (scs:...) (Scan SubString) verb when combined with (ACCEPT) in src/pcre2match.c. This vulnerability may potentially lead to information disclosure if the out-of-bounds data read during the memcmp affects the final match result in a way observable by the attacker. This issue has been resolved in version 10.46.

Integer overflow vulnerability in pcre2test before 10.41 allows attackers to cause a denial of service or other unspecified impacts via negative input.

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.

Perl-Compatible Regular Expression (PCRE) library before 7.3 backtracks too far when matching certain input bytes against some regex patterns in non-UTF-8 mode, which allows context-dependent attackers to obtain sensitive information or cause a denial of service (crash), as demonstrated by the "\X?\d" and "\P{L}?\d" patterns.

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.

Buffer overflow in PCRE before 7.6 allows remote attackers to execute arbitrary code via a regular expression containing a character class with a large number of characters with Unicode code points greater than 255.

A denial of service flaw was found in the way syslog-ng processed certain log patterns, when 'global' flag was speficied and PCRE backend was used for matching. A remote attacker could use this flaw to cause excessive memory use by the syslog-ng process via specially-crafted pattern.

References: [1] http://www.securityfocus.com/bid/47800/info [2] https://lists.balabit.hu/pipermail/syslog-ng/2011-May/016576.html

Upstream patch: [3] http://git.balabit.hu/?p=bazsi/syslog-ng-3.2.git;a=commit;h=09710c0b105e579d35c7b5f6c66d1ea5e3a3d3ff