|
1 | 1 | ChangeLog for PCRE |
2 | 2 | ------------------ |
3 | 3 |
|
| 4 | +Version 8.37 28-April-2015 |
| 5 | +-------------------------- |
| 6 | + |
| 7 | +1. When an (*ACCEPT) is triggered inside capturing parentheses, it arranges |
| 8 | + for those parentheses to be closed with whatever has been captured so far. |
| 9 | + However, it was failing to mark any other groups between the hightest |
| 10 | + capture so far and the currrent group as "unset". Thus, the ovector for |
| 11 | + those groups contained whatever was previously there. An example is the |
| 12 | + pattern /(x)|((*ACCEPT))/ when matched against "abcd". |
| 13 | + |
| 14 | +2. If an assertion condition was quantified with a minimum of zero (an odd |
| 15 | + thing to do, but it happened), SIGSEGV or other misbehaviour could occur. |
| 16 | + |
| 17 | +3. If a pattern in pcretest input had the P (POSIX) modifier followed by an |
| 18 | + unrecognized modifier, a crash could occur. |
| 19 | + |
| 20 | +4. An attempt to do global matching in pcretest with a zero-length ovector |
| 21 | + caused a crash. |
| 22 | + |
| 23 | +5. Fixed a memory leak during matching that could occur for a subpattern |
| 24 | + subroutine call (recursive or otherwise) if the number of captured groups |
| 25 | + that had to be saved was greater than ten. |
| 26 | + |
| 27 | +6. Catch a bad opcode during auto-possessification after compiling a bad UTF |
| 28 | + string with NO_UTF_CHECK. This is a tidyup, not a bug fix, as passing bad |
| 29 | + UTF with NO_UTF_CHECK is documented as having an undefined outcome. |
| 30 | + |
| 31 | +7. A UTF pattern containing a "not" match of a non-ASCII character and a |
| 32 | + subroutine reference could loop at compile time. Example: /[^\xff]((?1))/. |
| 33 | + |
| 34 | +8. When a pattern is compiled, it remembers the highest back reference so that |
| 35 | + when matching, if the ovector is too small, extra memory can be obtained to |
| 36 | + use instead. A conditional subpattern whose condition is a check on a |
| 37 | + capture having happened, such as, for example in the pattern |
| 38 | + /^(?:(a)|b)(?(1)A|B)/, is another kind of back reference, but it was not |
| 39 | + setting the highest backreference number. This mattered only if pcre_exec() |
| 40 | + was called with an ovector that was too small to hold the capture, and there |
| 41 | + was no other kind of back reference (a situation which is probably quite |
| 42 | + rare). The effect of the bug was that the condition was always treated as |
| 43 | + FALSE when the capture could not be consulted, leading to a incorrect |
| 44 | + behaviour by pcre_exec(). This bug has been fixed. |
| 45 | + |
| 46 | +9. A reference to a duplicated named group (either a back reference or a test |
| 47 | + for being set in a conditional) that occurred in a part of the pattern where |
| 48 | + PCRE_DUPNAMES was not set caused the amount of memory needed for the pattern |
| 49 | + to be incorrectly calculated, leading to overwriting. |
| 50 | + |
| 51 | +10. A mutually recursive set of back references such as (\2)(\1) caused a |
| 52 | + segfault at study time (while trying to find the minimum matching length). |
| 53 | + The infinite loop is now broken (with the minimum length unset, that is, |
| 54 | + zero). |
| 55 | + |
| 56 | +11. If an assertion that was used as a condition was quantified with a minimum |
| 57 | + of zero, matching went wrong. In particular, if the whole group had |
| 58 | + unlimited repetition and could match an empty string, a segfault was |
| 59 | + likely. The pattern (?(?=0)?)+ is an example that caused this. Perl allows |
| 60 | + assertions to be quantified, but not if they are being used as conditions, |
| 61 | + so the above pattern is faulted by Perl. PCRE has now been changed so that |
| 62 | + it also rejects such patterns. |
| 63 | + |
| 64 | +12. A possessive capturing group such as (a)*+ with a minimum repeat of zero |
| 65 | + failed to allow the zero-repeat case if pcre2_exec() was called with an |
| 66 | + ovector too small to capture the group. |
| 67 | + |
| 68 | +13. Fixed two bugs in pcretest that were discovered by fuzzing and reported by |
| 69 | + Red Hat Product Security: |
| 70 | + |
| 71 | + (a) A crash if /K and /F were both set with the option to save the compiled |
| 72 | + pattern. |
| 73 | + |
| 74 | + (b) Another crash if the option to print captured substrings in a callout |
| 75 | + was combined with setting a null ovector, for example \O\C+ as a subject |
| 76 | + string. |
| 77 | + |
| 78 | +14. A pattern such as "((?2){0,1999}())?", which has a group containing a |
| 79 | + forward reference repeated a large (but limited) number of times within a |
| 80 | + repeated outer group that has a zero minimum quantifier, caused incorrect |
| 81 | + code to be compiled, leading to the error "internal error: |
| 82 | + previously-checked referenced subpattern not found" when an incorrect |
| 83 | + memory address was read. This bug was reported as "heap overflow", |
| 84 | + discovered by Kai Lu of Fortinet's FortiGuard Labs and given the CVE number |
| 85 | + CVE-2015-2325. |
| 86 | + |
| 87 | +23. A pattern such as "((?+1)(\1))/" containing a forward reference subroutine |
| 88 | + call within a group that also contained a recursive back reference caused |
| 89 | + incorrect code to be compiled. This bug was reported as "heap overflow", |
| 90 | + discovered by Kai Lu of Fortinet's FortiGuard Labs, and given the CVE |
| 91 | + number CVE-2015-2326. |
| 92 | + |
| 93 | +24. Computing the size of the JIT read-only data in advance has been a source |
| 94 | + of various issues, and new ones are still appear unfortunately. To fix |
| 95 | + existing and future issues, size computation is eliminated from the code, |
| 96 | + and replaced by on-demand memory allocation. |
| 97 | + |
| 98 | +25. A pattern such as /(?i)[A-`]/, where characters in the other case are |
| 99 | + adjacent to the end of the range, and the range contained characters with |
| 100 | + more than one other case, caused incorrect behaviour when compiled in UTF |
| 101 | + mode. In that example, the range a-j was left out of the class. |
| 102 | + |
| 103 | +26. Fix JIT compilation of conditional blocks, which assertion |
| 104 | + is converted to (*FAIL). E.g: /(?(?!))/. |
| 105 | + |
| 106 | +27. The pattern /(?(?!)^)/ caused references to random memory. This bug was |
| 107 | + discovered by the LLVM fuzzer. |
| 108 | + |
| 109 | +28. The assertion (?!) is optimized to (*FAIL). This was not handled correctly |
| 110 | + when this assertion was used as a condition, for example (?(?!)a|b). In |
| 111 | + pcre2_match() it worked by luck; in pcre2_dfa_match() it gave an incorrect |
| 112 | + error about an unsupported item. |
| 113 | + |
| 114 | +29. For some types of pattern, for example /Z*(|d*){216}/, the auto- |
| 115 | + possessification code could take exponential time to complete. A recursion |
| 116 | + depth limit of 1000 has been imposed to limit the resources used by this |
| 117 | + optimization. |
| 118 | + |
| 119 | +30. A pattern such as /(*UTF)[\S\V\H]/, which contains a negated special class |
| 120 | + such as \S in non-UCP mode, explicit wide characters (> 255) can be ignored |
| 121 | + because \S ensures they are all in the class. The code for doing this was |
| 122 | + interacting badly with the code for computing the amount of space needed to |
| 123 | + compile the pattern, leading to a buffer overflow. This bug was discovered |
| 124 | + by the LLVM fuzzer. |
| 125 | + |
| 126 | +31. A pattern such as /((?2)+)((?1))/ which has mutual recursion nested inside |
| 127 | + other kinds of group caused stack overflow at compile time. This bug was |
| 128 | + discovered by the LLVM fuzzer. |
| 129 | + |
| 130 | +32. A pattern such as /(?1)(?#?'){8}(a)/ which had a parenthesized comment |
| 131 | + between a subroutine call and its quantifier was incorrectly compiled, |
| 132 | + leading to buffer overflow or other errors. This bug was discovered by the |
| 133 | + LLVM fuzzer. |
| 134 | + |
| 135 | +33. The illegal pattern /(?(?<E>.*!.*)?)/ was not being diagnosed as missing an |
| 136 | + assertion after (?(. The code was failing to check the character after |
| 137 | + (?(?< for the ! or = that would indicate a lookbehind assertion. This bug |
| 138 | + was discovered by the LLVM fuzzer. |
| 139 | + |
| 140 | +34. A pattern such as /X((?2)()*+){2}+/ which has a possessive quantifier with |
| 141 | + a fixed maximum following a group that contains a subroutine reference was |
| 142 | + incorrectly compiled and could trigger buffer overflow. This bug was |
| 143 | + discovered by the LLVM fuzzer. |
| 144 | + |
| 145 | +35. A mutual recursion within a lookbehind assertion such as (?<=((?2))((?1))) |
| 146 | + caused a stack overflow instead of the diagnosis of a non-fixed length |
| 147 | + lookbehind assertion. This bug was discovered by the LLVM fuzzer. |
| 148 | + |
| 149 | +36. The use of \K in a positive lookbehind assertion in a non-anchored pattern |
| 150 | + (e.g. /(?<=\Ka)/) could make pcregrep loop. |
| 151 | + |
| 152 | +37. There was a similar problem to 36 in pcretest for global matches. |
| 153 | + |
| 154 | +38. If a greedy quantified \X was preceded by \C in UTF mode (e.g. \C\X*), |
| 155 | + and a subsequent item in the pattern caused a non-match, backtracking over |
| 156 | + the repeated \X did not stop, but carried on past the start of the subject, |
| 157 | + causing reference to random memory and/or a segfault. There were also some |
| 158 | + other cases where backtracking after \C could crash. This set of bugs was |
| 159 | + discovered by the LLVM fuzzer. |
| 160 | + |
| 161 | +39. The function for finding the minimum length of a matching string could take |
| 162 | + a very long time if mutual recursion was present many times in a pattern, |
| 163 | + for example, /((?2){73}(?2))((?1))/. A better mutual recursion detection |
| 164 | + method has been implemented. This infelicity was discovered by the LLVM |
| 165 | + fuzzer. |
| 166 | + |
| 167 | +40. Static linking against the PCRE library using the pkg-config module was |
| 168 | + failing on missing pthread symbols. |
| 169 | + |
| 170 | + |
4 | 171 | Version 8.36 26-September-2014 |
5 | 172 | ------------------------------ |
6 | 173 |
|
|
0 commit comments