| 41 |
|
|
| 42 |
10. The PCRE_EXP_DEFN macro which precedes exported functions was missing from |
10. The PCRE_EXP_DEFN macro which precedes exported functions was missing from |
| 43 |
the convenience functions in the pcre_get.c source file. |
the convenience functions in the pcre_get.c source file. |
| 44 |
|
|
| 45 |
|
11. An option change at the start of a pattern that had top-level alternatives |
| 46 |
|
could cause overwriting and/or a crash. This command provoked a crash in |
| 47 |
|
some environments: |
| 48 |
|
|
| 49 |
|
printf "/(?i)[\xc3\xa9\xc3\xbd]|[\xc3\xa9\xc3\xbdA]/8\n" | pcretest |
| 50 |
|
|
| 51 |
|
This potential security problem was recorded as CVE-2008-2371. |
| 52 |
|
|
| 53 |
|
12. For a pattern where the match had to start at the beginning or immediately |
| 54 |
|
after a newline (e.g /.*anything/ without the DOTALL flag), pcre_exec() and |
| 55 |
|
pcre_dfa_exec() could read past the end of the passed subject if there was |
| 56 |
|
no match. To help with detecting such bugs (e.g. with valgrind), I modified |
| 57 |
|
pcretest so that it places the subject at the end of its malloc-ed buffer. |
| 58 |
|
|
| 59 |
|
13. The change to pcretest in 12 above threw up a couple more cases when pcre_ |
| 60 |
|
exec() might read past the end of the data buffer in UTF-8 mode. |
| 61 |
|
|
| 62 |
|
14. A similar bug to 7.3/2 existed when the PCRE_FIRSTLINE option was set and |
| 63 |
|
the data contained the byte 0x85 as part of a UTF-8 character within its |
| 64 |
|
first line. |
| 65 |
|
|
| 66 |
|
|
| 67 |
Version 7.7 07-May-08 |
Version 7.7 07-May-08 |
Parent Directory
| 
Revision Log
| 
Patch