diff options
author | wiz <wiz@pkgsrc.org> | 2015-11-24 11:04:03 +0000 |
---|---|---|
committer | wiz <wiz@pkgsrc.org> | 2015-11-24 11:04:03 +0000 |
commit | 97db8d6464c2ac87a861aa3428f7ff388207e1aa (patch) | |
tree | 244b0966e823c4f8823733959774c84b7ca985a6 /devel | |
parent | 494b563ebc2e9e40cb795840c2d749705eacc2c5 (diff) | |
download | pkgsrc-97db8d6464c2ac87a861aa3428f7ff388207e1aa.tar.gz |
Update pcre to 8.38:
Version 8.38 23-November-2015
-----------------------------
1. If a group that contained a recursive back reference also contained a
forward reference subroutine call followed by a non-forward-reference
subroutine call, for example /.((?2)(?R)\1)()/, pcre2_compile() failed to
compile correct code, leading to undefined behaviour or an internally
detected error. This bug was discovered by the LLVM fuzzer.
2. Quantification of certain items (e.g. atomic back references) could cause
incorrect code to be compiled when recursive forward references were
involved. For example, in this pattern: /(?1)()((((((\1++))\x85)+)|))/.
This bug was discovered by the LLVM fuzzer.
3. A repeated conditional group whose condition was a reference by name caused
a buffer overflow if there was more than one group with the given name.
This bug was discovered by the LLVM fuzzer.
4. A recursive back reference by name within a group that had the same name as
another group caused a buffer overflow. For example:
/(?J)(?'d'(?'d'\g{d}))/. This bug was discovered by the LLVM fuzzer.
5. A forward reference by name to a group whose number is the same as the
current group, for example in this pattern: /(?|(\k'Pm')|(?'Pm'))/, caused
a buffer overflow at compile time. This bug was discovered by the LLVM
fuzzer.
6. A lookbehind assertion within a set of mutually recursive subpatterns could
provoke a buffer overflow. This bug was discovered by the LLVM fuzzer.
7. Another buffer overflow bug involved duplicate named groups with a
reference between their definition, with a group that reset capture
numbers, for example: /(?J:(?|(?'R')(\k'R')|((?'R'))))/. This has been
fixed by always allowing for more memory, even if not needed. (A proper fix
is implemented in PCRE2, but it involves more refactoring.)
8. There was no check for integer overflow in subroutine calls such as (?123).
9. The table entry for \l in EBCDIC environments was incorrect, leading to its
being treated as a literal 'l' instead of causing an error.
10. There was a buffer overflow if pcre_exec() was called with an ovector of
size 1. This bug was found by american fuzzy lop.
11. If a non-capturing group containing a conditional group that could match
an empty string was repeated, it was not identified as matching an empty
string itself. For example: /^(?:(?(1)x|)+)+$()/.
12. In an EBCDIC environment, pcretest was mishandling the escape sequences
\a and \e in test subject lines.
13. In an EBCDIC environment, \a in a pattern was converted to the ASCII
instead of the EBCDIC value.
14. The handling of \c in an EBCDIC environment has been revised so that it is
now compatible with the specification in Perl's perlebcdic page.
15. The EBCDIC character 0x41 is a non-breaking space, equivalent to 0xa0 in
ASCII/Unicode. This has now been added to the list of characters that are
recognized as white space in EBCDIC.
16. When PCRE was compiled without UCP support, the use of \p and \P gave an
error (correctly) when used outside a class, but did not give an error
within a class.
17. \h within a class was incorrectly compiled in EBCDIC environments.
18. A pattern with an unmatched closing parenthesis that contained a backward
assertion which itself contained a forward reference caused buffer
overflow. And example pattern is: /(?=di(?<=(?1))|(?=(.))))/.
19. JIT should return with error when the compiled pattern requires more stack
space than the maximum.
20. A possessively repeated conditional group that could match an empty string,
for example, /(?(R))*+/, was incorrectly compiled.
21. Fix infinite recursion in the JIT compiler when certain patterns such as
/(?:|a|){100}x/ are analysed.
22. Some patterns with character classes involving [: and \\ were incorrectly
compiled and could cause reading from uninitialized memory or an incorrect
error diagnosis.
23. Pathological patterns containing many nested occurrences of [: caused
pcre_compile() to run for a very long time.
24. A conditional group with only one branch has an implicit empty alternative
branch and must therefore be treated as potentially matching an empty
string.
25. If (?R was followed by - or + incorrect behaviour happened instead of a
diagnostic.
26. Arrange to give up on finding the minimum matching length for overly
complex patterns.
27. Similar to (4) above: in a pattern with duplicated named groups and an
occurrence of (?| it is possible for an apparently non-recursive back
reference to become recursive if a later named group with the relevant
number is encountered. This could lead to a buffer overflow. Wen Guanxing
from Venustech ADLAB discovered this bug.
28. If pcregrep was given the -q option with -c or -l, or when handling a
binary file, it incorrectly wrote output to stdout.
29. The JIT compiler did not restore the control verb head in case of *THEN
control verbs. This issue was found by Karl Skomski with a custom LLVM
fuzzer.
30. Error messages for syntax errors following \g and \k were giving inaccurate
offsets in the pattern.
31. Added a check for integer overflow in conditions (?(<digits>) and
(?(R<digits>). This omission was discovered by Karl Skomski with the LLVM
fuzzer.
32. Handling recursive references such as (?2) when the reference is to a group
later in the pattern uses code that is very hacked about and error-prone.
It has been re-written for PCRE2. Here in PCRE1, a check has been added to
give an internal error if it is obvious that compiling has gone wrong.
33. The JIT compiler should not check repeats after a {0,1} repeat byte code.
This issue was found by Karl Skomski with a custom LLVM fuzzer.
34. The JIT compiler should restore the control chain for empty possessive
repeats. This issue was found by Karl Skomski with a custom LLVM fuzzer.
35. Match limit check added to JIT recursion. This issue was found by Karl
Skomski with a custom LLVM fuzzer.
36. Yet another case similar to 27 above has been circumvented by an
unconditional allocation of extra memory. This issue is fixed "properly" in
PCRE2 by refactoring the way references are handled. Wen Guanxing
from Venustech ADLAB discovered this bug.
37. Fix two assertion fails in JIT. These issues were found by Karl Skomski
with a custom LLVM fuzzer.
38. Fixed a corner case of range optimization in JIT.
39. An incorrect error "overran compiling workspace" was given if there were
exactly enough group forward references such that the last one extended
into the workspace safety margin. The next one would have expanded the
workspace. The test for overflow was not including the safety margin.
40. A match limit issue is fixed in JIT which was found by Karl Skomski
with a custom LLVM fuzzer.
41. Remove the use of /dev/null in testdata/testinput2, because it doesn't
work under Windows. (Why has it taken so long for anyone to notice?)
42. In a character class such as [\W\p{Any}] where both a negative-type escape
("not a word character") and a property escape were present, the property
escape was being ignored.
43. Fix crash caused by very long (*MARK) or (*THEN) names.
44. A sequence such as [[:punct:]b] that is, a POSIX character class followed
by a single ASCII character in a class item, was incorrectly compiled in
UCP mode. The POSIX class got lost, but only if the single character
followed it.
45. [:punct:] in UCP mode was matching some characters in the range 128-255
that should not have been matched.
46. If [:^ascii:] or [:^xdigit:] or [:^cntrl:] are present in a non-negated
class, all characters with code points greater than 255 are in the class.
When a Unicode property was also in the class (if PCRE_UCP is set, escapes
such as \w are turned into Unicode properties), wide characters were not
correctly handled, and could fail to match.
Diffstat (limited to 'devel')
-rw-r--r-- | devel/pcre/Makefile | 4 | ||||
-rw-r--r-- | devel/pcre/distinfo | 10 |
2 files changed, 7 insertions, 7 deletions
diff --git a/devel/pcre/Makefile b/devel/pcre/Makefile index 5d633976fb8..0195267dd6b 100644 --- a/devel/pcre/Makefile +++ b/devel/pcre/Makefile @@ -1,6 +1,6 @@ -# $NetBSD: Makefile,v 1.76 2015/04/29 11:24:48 mef Exp $ +# $NetBSD: Makefile,v 1.77 2015/11/24 11:04:03 wiz Exp $ -DISTNAME= pcre-8.37 +DISTNAME= pcre-8.38 CATEGORIES= devel MASTER_SITES= ftp://ftp.csx.cam.ac.uk/pub/software/programming/pcre/ \ ${MASTER_SITE_SOURCEFORGE:=pcre/} diff --git a/devel/pcre/distinfo b/devel/pcre/distinfo index 3c4a42ecb7d..4e1e24851b8 100644 --- a/devel/pcre/distinfo +++ b/devel/pcre/distinfo @@ -1,9 +1,9 @@ -$NetBSD: distinfo,v 1.57 2015/11/03 03:29:01 agc Exp $ +$NetBSD: distinfo,v 1.58 2015/11/24 11:04:03 wiz Exp $ -SHA1 (pcre-8.37.tar.bz2) = 4c629b3f582366fae4e8912f0d9fa3140347d6e7 -RMD160 (pcre-8.37.tar.bz2) = 2f38e201b921a9dc73ab7d555cc58a4320c599e5 -SHA512 (pcre-8.37.tar.bz2) = 19344c9add2ebbd26c528505d07d3b028d79bc3e6103d51453a449cebd76bc76f5bc7ddd9ef0de41f98c50be74a2d9a65db539ed60f1add1086d99bde8a81466 -Size (pcre-8.37.tar.bz2) = 1557603 bytes +SHA1 (pcre-8.38.tar.bz2) = ae84e3b3ef0764788ce33b1adeff1add938126e1 +RMD160 (pcre-8.38.tar.bz2) = eba6da5ef34780f63f8b96c60bd70ac197df3b52 +SHA512 (pcre-8.38.tar.bz2) = ad3412ceee8f992787a3e7cbe0155ffba67affd4b2dfece6c4501dc8d2012f52dcc1ee1f56759362e04bbbd10ea9370b3e46f238e2f75005cb69f6c8439e52c0 +Size (pcre-8.38.tar.bz2) = 1562265 bytes SHA1 (patch-aa) = ed20cfb5ca7b1e620e368c8e41a7f691d6f93282 SHA1 (patch-ab) = 0b8fbde09c27e2716e5bfa32abce8ee4a79fb7fb SHA1 (patch-doc_pcredemo.3) = 90f9b3a021f58973149d839735d40c5e2e245912 |