summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorbsiegert <bsiegert>2015-11-24 19:49:25 +0000
committerbsiegert <bsiegert>2015-11-24 19:49:25 +0000
commitc50de2f3343ac2306f3a9b0db0114e9bb62ca65f (patch)
tree4f041a5ea2d73594c4d91fdb4771d4a5b5899792
parent63b3fc076631584eb67af8a5084d0813bc36bc04 (diff)
downloadpkgsrc-c50de2f3343ac2306f3a9b0db0114e9bb62ca65f.tar.gz
Pullup ticket #4864 - requested by wiz
devel/pcre: security fix Revisions pulled up: - devel/pcre/Makefile 1.77 - devel/pcre/distinfo 1.58 --- Module Name: pkgsrc Committed By: wiz Date: Tue Nov 24 11:04:03 UTC 2015 Modified Files: pkgsrc/devel/pcre: Makefile distinfo Log Message: 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.
-rw-r--r--devel/pcre/Makefile4
-rw-r--r--devel/pcre/distinfo9
2 files changed, 7 insertions, 6 deletions
diff --git a/devel/pcre/Makefile b/devel/pcre/Makefile
index 5d633976fb8..4b18092fb0a 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.76.4.1 2015/11/24 19:49:25 bsiegert 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 c483c69cd85..06d2fc797bb 100644
--- a/devel/pcre/distinfo
+++ b/devel/pcre/distinfo
@@ -1,8 +1,9 @@
-$NetBSD: distinfo,v 1.56 2015/04/29 11:24:48 mef Exp $
+$NetBSD: distinfo,v 1.56.4.1 2015/11/24 19:49:25 bsiegert Exp $
-SHA1 (pcre-8.37.tar.bz2) = 4c629b3f582366fae4e8912f0d9fa3140347d6e7
-RMD160 (pcre-8.37.tar.bz2) = 2f38e201b921a9dc73ab7d555cc58a4320c599e5
-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