Tavis Ormandy of the Google Security team reported a heap overflow issue
The problem is that when an option is specified at the start of a pattern, to
avoid compiling it unnecessarily into the bytecode it's passed back up to the
caller as if it was specified via pcre_compile() options, i.e. /(?i)a|b/ ==
/a|b/i, and as the latter is somewhat easier to handle, they're made equivalent.
This usually works, but when a pattern contains multiple branches, the new
option is accidentally passed back too far, so when there are multiple branches,
only the first gets the new flag, however on the second compile pass the new
flag is always set, resulting in a mismatch between the size-calculation pass
and the actual compilation pass. The result is pcre overflowing a heap buffer.
Tavis' proposed patch:
--- pcre_compile.c~ 2008-06-12 16:55:22.860930000 +0200
+++ pcre_compile.c 2008-06-12 16:54:53.647168000 +0200
@@ -4931,7 +4931,7 @@
(lengthptr == NULL || *lengthptr == 2 + 2*LINK_SIZE))
cd->external_options = newoptions;
+ options = *optionsptr = newoptions;
- options = newoptions;
This issue did not affect the versions of pcre as shipped with Red Hat
Enterprise Linux 2.1, 3, 4, or 5.
This issue only affects pcre 7.x versions, so all current Fedora versions are
Public now via:
glib2-2.14.6-2.fc8 has been pushed to the Fedora 8 stable repository. If problems still persist, please make note of it in this bug report.
glib2-2.16.4-1.fc9 has been pushed to the Fedora 9 stable repository. If problems still persist, please make note of it in this bug report.
pcre-7.3-4.fc9 has been pushed to the Fedora 9 stable repository. If problems still persist, please make note of it in this bug report.
pcre-7.3-4.fc8 has been pushed to the Fedora 8 stable repository. If problems still persist, please make note of it in this bug report.
This issue was addressed in:
Created attachment 311810 [details]
Upstream patch in comment #14 applied upstream in SVN r360: