While fuzzing PCRE2, I found a case in which pcre2_compile may incorrectly read past the end of the pattern string which it is given. Here are the details:
Patterns passed to pcre2_compile are not guaranteed to be null-terminated. Also, it can happen that there is an invalid pattern like this:
(*LIMIT_HEAP=123
If the next byte of memory after the end of the pattern happens to be a digit, it will be parsed as part of the limit value. Or, if the next byte is a right parenthesis character, it will be taken as the end of the (*LIMIT_HEAP=nnn) construct.
This will result in skipatstart being larger than patlen, which will result in underflow and an erroneous call to malloc requesting a huge number of bytes.
While fuzzing PCRE2, I found a case in which
pcre2_compile
may incorrectly read past the end of the pattern string which it is given. Here are the details:Patterns passed to
pcre2_compile
are not guaranteed to be null-terminated. Also, it can happen that there is an invalid pattern like this:If the next byte of memory after the end of the pattern happens to be a digit, it will be parsed as part of the limit value. Or, if the next byte is a right parenthesis character, it will be taken as the end of the
(*LIMIT_HEAP=nnn)
construct.This will result in
skipatstart
being larger thanpatlen
, which will result in underflow and an erroneous call to malloc requesting a huge number of bytes.