In PCRE2 before 10.48, pcre2jitmatch mishandles a previously copied subject being passed in as a context. An incorrect free operation can occur.

PCRE2 before 10.49, when there is an attacker-controlled regular expression and certain JIT API usage, allows an out-of-bounds write with arbitrary data.

PCRE2 before 10.48, on 32-bit platforms, has a pcre2patternconvert out-of-bounds write when an attacker can provide a large pattern.

PCRE2 before 10.48 has a pcre2match out-of-bounds read during the PCRE2MATCHINVALIDUTF matching of an invalid UTF subject.

PCRE2 before 10.48, on 32-bit platforms, has a pcre2compile32 integer overflow and resultant out-of-bounds write.

PCRE2 before 10.48 has a pcre2match out-of-bounds read after a JIT fallback when an attacker can provide invalid UTF data.

In PCRE2 before 10.48, pcre2serializeencode might disclose two bytes to an adversary, typically in a situation where the access available to the adversary is already unsafe.

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

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

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.

pcre2test.c in PCRE2 10.23 allows remote attackers to cause a denial of service (heap-based buffer overflow) or possibly have unspecified other impact via a crafted regular expression.

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

An out-of-bounds read vulnerability was discovered in the PCRE2 library in the getrecursedatalength() function of the pcre2jitcompile.c file. This issue affects recursions in JIT-compiled regular expressions caused by duplicate data transfers.

Fixed bug (applied upstream patch for CVE-2016-1283).

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 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 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.

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.

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.

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.

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.