| 49 |
printf "/(?i)[\xc3\xa9\xc3\xbd]|[\xc3\xa9\xc3\xbdA]/8\n" | pcretest |
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. |
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