/[pcre]/code/trunk/ChangeLog
ViewVC logotype

Diff of /code/trunk/ChangeLog

Parent Directory Parent Directory | Revision Log Revision Log | View Patch Patch

revision 1576 by ph10, Fri Jul 17 15:15:18 2015 UTC revision 1604 by ph10, Tue Nov 17 17:27:17 2015 UTC
# Line 1  Line 1 
1  ChangeLog for PCRE  ChangeLog for PCRE
2  ------------------  ------------------
3    
4  Note that the PCRE 8.xx series (PCRE1) is now in a bugfix-only state. All  Note that the PCRE 8.xx series (PCRE1) is now in a bugfix-only state. All
5  development is happening in the PCRE2 10.xx series.  development is happening in the PCRE2 10.xx series.
6    
7  Version 8.38 xx-xxx-xxxx  Version 8.38 27-October-2015
8  ------------------------  ----------------------------
9    
10  1.  If a group that contained a recursive back reference also contained a  1.  If a group that contained a recursive back reference also contained a
11      forward reference subroutine call followed by a non-forward-reference      forward reference subroutine call followed by a non-forward-reference
12      subroutine call, for example /.((?2)(?R)\1)()/, pcre2_compile() failed to      subroutine call, for example /.((?2)(?R)\1)()/, pcre2_compile() failed to
13      compile correct code, leading to undefined behaviour or an internally      compile correct code, leading to undefined behaviour or an internally
14      detected error. This bug was discovered by the LLVM fuzzer.      detected error. This bug was discovered by the LLVM fuzzer.
15    
16  2.  Quantification of certain items (e.g. atomic back references) could cause  2.  Quantification of certain items (e.g. atomic back references) could cause
17      incorrect code to be compiled when recursive forward references were      incorrect code to be compiled when recursive forward references were
18      involved. For example, in this pattern: /(?1)()((((((\1++))\x85)+)|))/.      involved. For example, in this pattern: /(?1)()((((((\1++))\x85)+)|))/.
19      This bug was discovered by the LLVM fuzzer.      This bug was discovered by the LLVM fuzzer.
20    
21  3.  A repeated conditional group whose condition was a reference by name caused  3.  A repeated conditional group whose condition was a reference by name caused
22      a buffer overflow if there was more than one group with the given name.      a buffer overflow if there was more than one group with the given name.
23      This bug was discovered by the LLVM fuzzer.      This bug was discovered by the LLVM fuzzer.
24    
25  4.  A recursive back reference by name within a group that had the same name as  4.  A recursive back reference by name within a group that had the same name as
26      another group caused a buffer overflow. For example:      another group caused a buffer overflow. For example:
27      /(?J)(?'d'(?'d'\g{d}))/. This bug was discovered by the LLVM fuzzer.      /(?J)(?'d'(?'d'\g{d}))/. This bug was discovered by the LLVM fuzzer.
# Line 30  Version 8.38 xx-xxx-xxxx Line 30  Version 8.38 xx-xxx-xxxx
30      current group, for example in this pattern: /(?|(\k'Pm')|(?'Pm'))/, caused      current group, for example in this pattern: /(?|(\k'Pm')|(?'Pm'))/, caused
31      a buffer overflow at compile time. This bug was discovered by the LLVM      a buffer overflow at compile time. This bug was discovered by the LLVM
32      fuzzer.      fuzzer.
33    
34  6.  A lookbehind assertion within a set of mutually recursive subpatterns could  6.  A lookbehind assertion within a set of mutually recursive subpatterns could
35      provoke a buffer overflow. This bug was discovered by the LLVM fuzzer.      provoke a buffer overflow. This bug was discovered by the LLVM fuzzer.
36    
37  7.  Another buffer overflow bug involved duplicate named groups with a  7.  Another buffer overflow bug involved duplicate named groups with a
38      reference between their definition, with a group that reset capture      reference between their definition, with a group that reset capture
39      numbers, for example: /(?J:(?|(?'R')(\k'R')|((?'R'))))/. This has been      numbers, for example: /(?J:(?|(?'R')(\k'R')|((?'R'))))/. This has been
40      fixed by always allowing for more memory, even if not needed. (A proper fix      fixed by always allowing for more memory, even if not needed. (A proper fix
41      is implemented in PCRE2, but it involves more refactoring.)      is implemented in PCRE2, but it involves more refactoring.)
42    
43  8.  There was no check for integer overflow in subroutine calls such as (?123).  8.  There was no check for integer overflow in subroutine calls such as (?123).
44    
45  9.  The table entry for \l in EBCDIC environments was incorrect, leading to its  9.  The table entry for \l in EBCDIC environments was incorrect, leading to its
46      being treated as a literal 'l' instead of causing an error.      being treated as a literal 'l' instead of causing an error.
47    
48  10. There was a buffer overflow if pcre_exec() was called with an ovector of  10. There was a buffer overflow if pcre_exec() was called with an ovector of
49      size 1. This bug was found by american fuzzy lop.      size 1. This bug was found by american fuzzy lop.
50    
51  11. If a non-capturing group containing a conditional group that could match  11. If a non-capturing group containing a conditional group that could match
52      an empty string was repeated, it was not identified as matching an empty      an empty string was repeated, it was not identified as matching an empty
53      string itself. For example: /^(?:(?(1)x|)+)+$()/.      string itself. For example: /^(?:(?(1)x|)+)+$()/.
54    
55  12. In an EBCDIC environment, pcretest was mishandling the escape sequences  12. In an EBCDIC environment, pcretest was mishandling the escape sequences
56      \a and \e in test subject lines.      \a and \e in test subject lines.
57    
58  13. In an EBCDIC environment, \a in a pattern was converted to the ASCII  13. In an EBCDIC environment, \a in a pattern was converted to the ASCII
59      instead of the EBCDIC value.      instead of the EBCDIC value.
60    
61  14. The handling of \c in an EBCDIC environment has been revised so that it is  14. The handling of \c in an EBCDIC environment has been revised so that it is
62      now compatible with the specification in Perl's perlebcdic page.      now compatible with the specification in Perl's perlebcdic page.
63    
64  15. The EBCDIC character 0x41 is a non-breaking space, equivalent to 0xa0 in  15. The EBCDIC character 0x41 is a non-breaking space, equivalent to 0xa0 in
65      ASCII/Unicode. This has now been added to the list of characters that are      ASCII/Unicode. This has now been added to the list of characters that are
66      recognized as white space in EBCDIC.      recognized as white space in EBCDIC.
67    
68  16. When PCRE was compiled without UCP support, the use of \p and \P gave an  16. When PCRE was compiled without UCP support, the use of \p and \P gave an
69      error (correctly) when used outside a class, but did not give an error      error (correctly) when used outside a class, but did not give an error
70      within a class.      within a class.
   
 17. \h within a class was incorrectly compiled in EBCDIC environments.  
71    
72  18. A pattern with an unmatched closing parenthesis that contained a backward  17. \h within a class was incorrectly compiled in EBCDIC environments.
73      assertion which itself contained a forward reference caused buffer  
74    18. A pattern with an unmatched closing parenthesis that contained a backward
75        assertion which itself contained a forward reference caused buffer
76      overflow. And example pattern is: /(?=di(?<=(?1))|(?=(.))))/.      overflow. And example pattern is: /(?=di(?<=(?1))|(?=(.))))/.
77    
78  19. JIT should return with error when the compiled pattern requires more stack  19. JIT should return with error when the compiled pattern requires more stack
# Line 81  Version 8.38 xx-xxx-xxxx Line 81  Version 8.38 xx-xxx-xxxx
81  20. A possessively repeated conditional group that could match an empty string,  20. A possessively repeated conditional group that could match an empty string,
82      for example, /(?(R))*+/, was incorrectly compiled.      for example, /(?(R))*+/, was incorrectly compiled.
83    
84    21. Fix infinite recursion in the JIT compiler when certain patterns such as
85        /(?:|a|){100}x/ are analysed.
86    
87    22. Some patterns with character classes involving [: and \\ were incorrectly
88        compiled and could cause reading from uninitialized memory or an incorrect
89        error diagnosis.
90    
91    23. Pathological patterns containing many nested occurrences of [: caused
92        pcre_compile() to run for a very long time.
93    
94    24. A conditional group with only one branch has an implicit empty alternative
95        branch and must therefore be treated as potentially matching an empty
96        string.
97    
98    25. If (?R was followed by - or + incorrect behaviour happened instead of a
99        diagnostic.
100    
101    26. Arrange to give up on finding the minimum matching length for overly
102        complex patterns.
103    
104    27. Similar to (4) above: in a pattern with duplicated named groups and an
105        occurrence of (?| it is possible for an apparently non-recursive back
106        reference to become recursive if a later named group with the relevant
107        number is encountered. This could lead to a buffer overflow. Wen Guanxing
108        from Venustech ADLAB discovered this bug.
109    
110    28. If pcregrep was given the -q option with -c or -l, or when handling a
111        binary file, it incorrectly wrote output to stdout.
112    
113    29. The JIT compiler did not restore the control verb head in case of *THEN
114        control verbs. This issue was found by Karl Skomski with a custom LLVM
115        fuzzer.
116    
117    30. Error messages for syntax errors following \g and \k were giving inaccurate
118        offsets in the pattern.
119    
120    31. Added a check for integer overflow in conditions (?(<digits>) and
121        (?(R<digits>). This omission was discovered by Karl Skomski with the LLVM
122        fuzzer.
123    
124    32. Handling recursive references such as (?2) when the reference is to a group
125        later in the pattern uses code that is very hacked about and error-prone.
126        It has been re-written for PCRE2. Here in PCRE1, a check has been added to
127        give an internal error if it is obvious that compiling has gone wrong.
128    
129    33. The JIT compiler should not check repeats after a {0,1} repeat byte code.
130        This issue was found by Karl Skomski with a custom LLVM fuzzer.
131    
132    34. The JIT compiler should restore the control chain for empty possessive
133        repeats. This issue was found by Karl Skomski with a custom LLVM fuzzer.
134    
135    35. Match limit check added to JIT recursion. This issue was found by Karl
136        Skomski with a custom LLVM fuzzer.
137    
138    36. Yet another case similar to 27 above has been circumvented by an
139        unconditional allocation of extra memory. This issue is fixed "properly" in
140        PCRE2 by refactoring the way references are handled. Wen Guanxing
141        from Venustech ADLAB discovered this bug.
142    
143    37. Fix two assertion fails in JIT. These issues were found by Karl Skomski
144        with a custom LLVM fuzzer.
145    
146    38. Fixed a corner case of range optimization in JIT.
147    
148    39. An incorrect error "overran compiling workspace" was given if there were
149        exactly enough group forward references such that the last one extended
150        into the workspace safety margin. The next one would have expanded the
151        workspace. The test for overflow was not including the safety margin.
152    
153    40. A match limit issue is fixed in JIT which was found by Karl Skomski
154        with a custom LLVM fuzzer.
155    
156    41. Remove the use of /dev/null in testdata/testinput2, because it doesn't
157        work under Windows. (Why has it taken so long for anyone to notice?)
158    
159    42. In a character class such as [\W\p{Any}] where both a negative-type escape
160        ("not a word character") and a property escape were present, the property
161        escape was being ignored.
162    
163    43. Fix crash caused by very long (*MARK) or (*THEN) names.
164    
165    44. A sequence such as [[:punct:]b] that is, a POSIX character class followed
166        by a single ASCII character in a class item, was incorrectly compiled in
167        UCP mode. The POSIX class got lost, but only if the single character
168        followed it.
169    
170    
171  Version 8.37 28-April-2015  Version 8.37 28-April-2015
172  --------------------------  --------------------------

Legend:
Removed from v.1576  
changed lines
  Added in v.1604

  ViewVC Help
Powered by ViewVC 1.1.5