@@ -4,12 +4,198 @@ ChangeLog for PCRE
44Note that the PCRE 8.xx series (PCRE1) is now in a bugfix-only state. All
55development is happening in the PCRE2 10.xx series.
66
7+ Version 8.41 05-July-2017
8+ -------------------------
9+
10+ 1. Fixed typo in CMakeLists.txt (wrong number of arguments for
11+ PCRE_STATIC_RUNTIME (affects MSVC only).
12+
13+ 2. Issue 1 for 8.40 below was not correctly fixed. If pcregrep in multiline
14+ mode with --only-matching matched several lines, it restarted scanning at the
15+ next line instead of moving on to the end of the matched string, which can be
16+ several lines after the start.
17+
18+ 3. Fix a missing else in the JIT compiler reported by 'idaifish'.
19+
20+ 4. A (?# style comment is now ignored between a basic quantifier and a
21+ following '+' or '?' (example: /X+(?#comment)?Y/.
22+
23+ 5. Avoid use of a potentially overflowing buffer in pcregrep (patch by Petr
24+ Pisar).
25+
26+ 6. Fuzzers have reported issues in pcretest. These are NOT serious (it is,
27+ after all, just a test program). However, to stop the reports, some easy ones
28+ are fixed:
29+
30+ (a) Check for values < 256 when calling isprint() in pcretest.
31+ (b) Give an error for too big a number after \O.
32+
33+ 7. In the 32-bit library in non-UTF mode, an attempt to find a Unicode
34+ property for a character with a code point greater than 0x10ffff (the Unicode
35+ maximum) caused a crash.
36+
37+ 8. The alternative matching function, pcre_dfa_exec() misbehaved if it
38+ encountered a character class with a possessive repeat, for example [a-f]{3}+.
39+
40+ 9. When pcretest called pcre_copy_substring() in 32-bit mode, it set the buffer
41+ length incorrectly, which could result in buffer overflow.
42+
43+ 10. Remove redundant line of code (accidentally left in ages ago).
44+
45+ 11. Applied C++ patch from Irfan Adilovic to guard 'using std::' directives
46+ with namespace pcrecpp (Bugzilla #2084).
47+
48+ 12. Remove a duplication typo in pcre_tables.c.
49+
50+ 13. Fix returned offsets from regexec() when REG_STARTEND is used with a
51+ starting offset greater than zero.
52+
53+
54+ Version 8.40 11-January-2017
55+ ----------------------------
56+
57+ 1. Using -o with -M in pcregrep could cause unnecessary repeated output when
58+ the match extended over a line boundary.
59+
60+ 2. Applied Chris Wilson's second patch (Bugzilla #1681) to CMakeLists.txt for
61+ MSVC static compilation, putting the first patch under a new option.
62+
63+ 3. Fix register overwite in JIT when SSE2 acceleration is enabled.
64+
65+ 4. Ignore "show all captures" (/=) for DFA matching.
66+
67+ 5. Fix JIT unaligned accesses on x86. Patch by Marc Mutz.
68+
69+ 6. In any wide-character mode (8-bit UTF or any 16-bit or 32-bit mode),
70+ without PCRE_UCP set, a negative character type such as \D in a positive
71+ class should cause all characters greater than 255 to match, whatever else
72+ is in the class. There was a bug that caused this not to happen if a
73+ Unicode property item was added to such a class, for example [\D\P{Nd}] or
74+ [\W\pL].
75+
76+ 7. When pcretest was outputing information from a callout, the caret indicator
77+ for the current position in the subject line was incorrect if it was after
78+ an escape sequence for a character whose code point was greater than
79+ \x{ff}.
80+
81+ 8. A pattern such as (?<RA>abc)(?(R)xyz) was incorrectly compiled such that
82+ the conditional was interpreted as a reference to capturing group 1 instead
83+ of a test for recursion. Any group whose name began with R was
84+ misinterpreted in this way. (The reference interpretation should only
85+ happen if the group's name is precisely "R".)
86+
87+ 9. A number of bugs have been mended relating to match start-up optimizations
88+ when the first thing in a pattern is a positive lookahead. These all
89+ applied only when PCRE_NO_START_OPTIMIZE was *not* set:
90+
91+ (a) A pattern such as (?=.*X)X$ was incorrectly optimized as if it needed
92+ both an initial 'X' and a following 'X'.
93+ (b) Some patterns starting with an assertion that started with .* were
94+ incorrectly optimized as having to match at the start of the subject or
95+ after a newline. There are cases where this is not true, for example,
96+ (?=.*[A-Z])(?=.{8,16})(?!.*[\s]) matches after the start in lines that
97+ start with spaces. Starting .* in an assertion is no longer taken as an
98+ indication of matching at the start (or after a newline).
99+
100+
101+ Version 8.39 14-June-2016
102+ -------------------------
103+
104+ 1. If PCRE_AUTO_CALLOUT was set on a pattern that had a (?# comment between
105+ an item and its qualifier (for example, A(?#comment)?B) pcre_compile()
106+ misbehaved. This bug was found by the LLVM fuzzer.
107+
108+ 2. Similar to the above, if an isolated \E was present between an item and its
109+ qualifier when PCRE_AUTO_CALLOUT was set, pcre_compile() misbehaved. This
110+ bug was found by the LLVM fuzzer.
111+
112+ 3. Further to 8.38/46, negated classes such as [^[:^ascii:]\d] were also not
113+ working correctly in UCP mode.
114+
115+ 4. The POSIX wrapper function regexec() crashed if the option REG_STARTEND
116+ was set when the pmatch argument was NULL. It now returns REG_INVARG.
117+
118+ 5. Allow for up to 32-bit numbers in the ordin() function in pcregrep.
119+
120+ 6. An empty \Q\E sequence between an item and its qualifier caused
121+ pcre_compile() to misbehave when auto callouts were enabled. This bug was
122+ found by the LLVM fuzzer.
123+
124+ 7. If a pattern that was compiled with PCRE_EXTENDED started with white
125+ space or a #-type comment that was followed by (?-x), which turns off
126+ PCRE_EXTENDED, and there was no subsequent (?x) to turn it on again,
127+ pcre_compile() assumed that (?-x) applied to the whole pattern and
128+ consequently mis-compiled it. This bug was found by the LLVM fuzzer.
129+
130+ 8. A call of pcre_copy_named_substring() for a named substring whose number
131+ was greater than the space in the ovector could cause a crash.
132+
133+ 9. Yet another buffer overflow bug involved duplicate named groups with a
134+ group that reset capture numbers (compare 8.38/7 below). Once again, I have
135+ just allowed for more memory, even if not needed. (A proper fix is
136+ implemented in PCRE2, but it involves a lot of refactoring.)
137+
138+ 10. pcre_get_substring_list() crashed if the use of \K in a match caused the
139+ start of the match to be earlier than the end.
140+
141+ 11. Migrating appropriate PCRE2 JIT improvements to PCRE.
142+
143+ 12. A pattern such as /(?<=((?C)0))/, which has a callout inside a lookbehind
144+ assertion, caused pcretest to generate incorrect output, and also to read
145+ uninitialized memory (detected by ASAN or valgrind).
146+
147+ 13. A pattern that included (*ACCEPT) in the middle of a sufficiently deeply
148+ nested set of parentheses of sufficient size caused an overflow of the
149+ compiling workspace (which was diagnosed, but of course is not desirable).
150+
151+ 14. And yet another buffer overflow bug involving duplicate named groups, this
152+ time nested, with a nested back reference. Yet again, I have just allowed
153+ for more memory, because anything more needs all the refactoring that has
154+ been done for PCRE2. An example pattern that provoked this bug is:
155+ /((?J)(?'R'(?'R'(?'R'(?'R'(?'R'(?|(\k'R'))))))))/ and the bug was
156+ registered as CVE-2016-1283.
157+
158+ 15. pcretest went into a loop if global matching was requested with an ovector
159+ size less than 2. It now gives an error message. This bug was found by
160+ afl-fuzz.
161+
162+ 16. An invalid pattern fragment such as (?(?C)0 was not diagnosing an error
163+ ("assertion expected") when (?(?C) was not followed by an opening
164+ parenthesis.
165+
166+ 17. Fixed typo ("&&" for "&") in pcre_study(). Fortunately, this could not
167+ actually affect anything, by sheer luck.
168+
169+ 18. Applied Chris Wilson's patch (Bugzilla #1681) to CMakeLists.txt for MSVC
170+ static compilation.
171+
172+ 19. Modified the RunTest script to incorporate a valgrind suppressions file so
173+ that certain errors, provoked by the SSE2 instruction set when JIT is used,
174+ are ignored.
175+
176+ 20. A racing condition is fixed in JIT reported by Mozilla.
177+
178+ 21. Minor code refactor to avoid "array subscript is below array bounds"
179+ compiler warning.
180+
181+ 22. Minor code refactor to avoid "left shift of negative number" warning.
182+
183+ 23. Fix typo causing compile error when 16- or 32-bit JIT is compiled without
184+ UCP support.
185+
186+ 24. Refactor to avoid compiler warnings in pcrecpp.cc.
187+
188+ 25. Refactor to fix a typo in pcre_jit_test.c
189+
190+ 26. Patch to support compiling pcrecpp.cc with Intel compiler.
191+
192+
7193Version 8.38 23-November-2015
8194-----------------------------
9195
101961. If a group that contained a recursive back reference also contained a
11197 forward reference subroutine call followed by a non-forward-reference
12- subroutine call, for example /.((?2)(?R)\1)()/, pcre2_compile () failed to
198+ subroutine call, for example /.((?2)(?R)\1)()/, pcre_compile () failed to
13199 compile correct code, leading to undefined behaviour or an internally
14200 detected error. This bug was discovered by the LLVM fuzzer.
15201
0 commit comments