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.