[pcre-dev] [Bug 1978] PCRE2 10.23-RC1 - Out of bounds read in internal_dfa_match()

https://bugs.exim.org/show_bug.cgi?id=1978 --- Comment #7 from Philip Hazel --- *** Bug 1989 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are on the CC list for the bug. -- ## List details at

[pcre-dev] [Bug 1989] PCRE2 10.23-RC1 - Heap out of bounds read in match() #4

https://bugs.exim.org/show_bug.cgi?id=1989 Philip Hazel changed: What|Removed |Added Resolution|--- |DUPLICATE

[pcre-dev] [Bug 1990] PCRE2 10.23-RC1 - Heap out of bounds read in match() #5

https://bugs.exim.org/show_bug.cgi?id=1990 Philip Hazel changed: What|Removed |Added Status|NEW |RESOLVED

[pcre-dev] [Bug 1986] PCRE2 10.23-RC1 - Heap out of bounds read in internal_dfa_match()

https://bugs.exim.org/show_bug.cgi?id=1986 Philip Hazel changed: What|Removed |Added Resolution|--- |INVALID

[pcre-dev] [Bug 1992] PCRE2 10.23-RC1 - Heap out of bounds read in pcre2_substitute_8()

https://bugs.exim.org/show_bug.cgi?id=1992 Philip Hazel changed: What|Removed |Added Status|NEW |RESOLVED

[pcre-dev] [Bug 1981] PCRE2 10.23-RC1 - Out of bounds read in match() #3

https://bugs.exim.org/show_bug.cgi?id=1981 Philip Hazel changed: What|Removed |Added Status|NEW |RESOLVED

[pcre-dev] [Bug 1983] PCRE2 10.23-RC1 - Heap out of bounds read in match() #1

https://bugs.exim.org/show_bug.cgi?id=1983 Philip Hazel changed: What|Removed |Added Status|NEW |RESOLVED

[pcre-dev] [Bug 1978] PCRE2 10.23-RC1 - Out of bounds read in internal_dfa_match()

https://bugs.exim.org/show_bug.cgi?id=1978 --- Comment #4 from Philip Hazel --- *** Bug 1983 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are on the CC list for the bug. -- ## List details at

[pcre-dev] [Bug 1987] PCRE2 10.23-RC1 - Heap out of bounds read in match() #3

https://bugs.exim.org/show_bug.cgi?id=1987 Philip Hazel changed: What|Removed |Added Status|NEW |RESOLVED

[pcre-dev] [Bug 1978] PCRE2 10.23-RC1 - Out of bounds read in internal_dfa_match()

https://bugs.exim.org/show_bug.cgi?id=1978 --- Comment #6 from Philip Hazel --- *** Bug 1987 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are on the CC list for the bug. -- ## List details at

[pcre-dev] [Bug 2009] sljitProtExecAllocator defines _XOPEN_SOURCE too late

https://bugs.exim.org/show_bug.cgi?id=2009 Christian Persch (GNOME) changed: What|Removed |Added Status|NEW |RESOLVED

[pcre-dev] [Bug 1749] PCRE-JITted code should be executed from non-writable memory to obey execmem SELinux restriction

https://bugs.exim.org/show_bug.cgi?id=1749 --- Comment #43 from Zoltan Herczeg --- > It's not good. > > Pass: aarch64, i686, x86_64 > Fail: armv7hl (SIGILL), ppc32 (SIGSEGV), ppc64be (SIGSEGV), ppc64le (SIGSEGV) > > You can see some results on >

[pcre-dev] [Bug 2010] sljitProtExecAllocator temp file descriptor isn't CLOEXEC

https://bugs.exim.org/show_bug.cgi?id=2010 --- Comment #3 from Christian Persch (GNOME) --- Created attachment 968 --> https://bugs.exim.org/attachment.cgi?id=968=edit patch series for comment I've created a patch series that implements what I think needs to be done for these

[pcre-dev] [Bug 2006] Stack Overflow in match()

https://bugs.exim.org/show_bug.cgi?id=2006 Philip Hazel changed: What|Removed |Added Resolution|--- |INVALID

[pcre-dev] [Bug 1749] PCRE-JITted code should be executed from non-writable memory to obey execmem SELinux restriction

https://bugs.exim.org/show_bug.cgi?id=1749 --- Comment #42 from Philip Hazel --- (In reply to Philip Hazel from comment #39) > ( > It is trivial, of course, to make pcre2grep ignore JIT compile errors. I have now done this. -- You are receiving this mail because: You

[pcre-dev] [Bug 2007] Stack Overflow in op_recurse_ovecsave()

https://bugs.exim.org/show_bug.cgi?id=2007 Philip Hazel changed: What|Removed |Added Status|NEW |RESOLVED

[pcre-dev] [Bug 2006] Stack Overflow in match()

https://bugs.exim.org/show_bug.cgi?id=2006 --- Comment #2 from Philip Hazel --- *** Bug 2007 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are on the CC list for the bug. -- ## List details at

[pcre-dev] [Bug 2008] [pcre2test] Heap out of bounds read in pchars8()

https://bugs.exim.org/show_bug.cgi?id=2008 Philip Hazel changed: What|Removed |Added Status|NEW |RESOLVED

[pcre-dev] [Bug 2010] sljitProtExecAllocator temp file descriptor isn't CLOEXEC

https://bugs.exim.org/show_bug.cgi?id=2010 --- Comment #4 from Zoltan Herczeg --- I landed a patch which takes the source code changes. I let Philip to decide the build system changes. I decided that mkostemp and secure_getenv are mandatory for this allocator, and the new

[pcre-dev] [Bug 1975] New: PCRE 10.23-RC1 - Heap out of bounds read in match()

https://bugs.exim.org/show_bug.cgi?id=1975 Bug ID: 1975 Summary: PCRE 10.23-RC1 - Heap out of bounds read in match() Product: PCRE Version: N/A Hardware: x86-64 OS: Linux Status: NEW Severity: bug

[pcre-dev] [Bug 1977] New: PCRE 10.23-RC1 - Null pointer dereference in _pcre2_check_escape_8()

https://bugs.exim.org/show_bug.cgi?id=1977 Bug ID: 1977 Summary: PCRE 10.23-RC1 - Null pointer dereference in _pcre2_check_escape_8() Product: PCRE Version: N/A Hardware: x86-64 OS: Linux

[pcre-dev] [Bug 1976] New: PCRE2 10.23-RC1 pcre2test - Out of bounds read in operatorString()

https://bugs.exim.org/show_bug.cgi?id=1976 Bug ID: 1976 Summary: PCRE2 10.23-RC1 pcre2test - Out of bounds read in operatorString() Product: PCRE Version: N/A Hardware: x86-64 OS: Linux Status:

[pcre-dev] [Bug 1975] PCRE2 10.23-RC1 - Heap out of bounds read in match()

https://bugs.exim.org/show_bug.cgi?id=1975 Kamil Frankowicz changed: What|Removed |Added Summary|PCRE 10.23-RC1 - Heap out |PCRE2 10.23-RC1 - Heap

[pcre-dev] [Bug 1973] New: small mem leaks in pcre2test exe

https://bugs.exim.org/show_bug.cgi?id=1973 Bug ID: 1973 Summary: small mem leaks in pcre2test exe Product: PCRE Version: N/A Hardware: All OS: All Status: NEW Severity: bug Priority: medium

[pcre-dev] [Bug 1749] PCRE-JITted code should be executed from non-writable memory to obey execmem SELinux restriction

https://bugs.exim.org/show_bug.cgi?id=1749 --- Comment #40 from Zoltan Herczeg --- Ok, then pcre2grep should just ignore the error. We can add an option to force an abort if it would be needed for testing. But I am not sure, pcregrep tests are not JIT tests. -- You are

[pcre-dev] [Bug 1749] PCRE-JITted code should be executed from non-writable memory to obey execmem SELinux restriction

https://bugs.exim.org/show_bug.cgi?id=1749 --- Comment #27 from Zoltan Herczeg --- I reworked the protected allocator to use temporary files, and added the support for x86. The code is available in PCRE2 repository. Please check whether it works on SE Linux. I will update

[pcre-dev] [Bug 1749] PCRE-JITted code should be executed from non-writable memory to obey execmem SELinux restriction

https://bugs.exim.org/show_bug.cgi?id=1749 --- Comment #28 from Petr Pisar --- I confirm it works even if SELinux is configured to deny RWX pages (deny_execmem SELinux boolean set to 1). Now to the mkstemp(). If you make /tmp nonwritable, JIT compilation fails with "no more

[pcre-dev] [Bug 1749] PCRE-JITted code should be executed from non-writable memory to obey execmem SELinux restriction

https://bugs.exim.org/show_bug.cgi?id=1749 --- Comment #30 from Philip Hazel --- (In reply to Zoltan Herczeg from comment #29) > Ok I will try to do these requests. Will take time. Is ./ a good idea to > create a temporary file? What other projects do btw? I would like to

[pcre-dev] [Bug 1749] PCRE-JITted code should be executed from non-writable memory to obey execmem SELinux restriction

https://bugs.exim.org/show_bug.cgi?id=1749 --- Comment #29 from Zoltan Herczeg --- Ok I will try to do these requests. Will take time. Is ./ a good idea to create a temporary file? What other projects do btw? -- You are receiving this mail because: You are on the CC list

[pcre-dev] [Bug 1749] PCRE-JITted code should be executed from non-writable memory to obey execmem SELinux restriction

https://bugs.exim.org/show_bug.cgi?id=1749 --- Comment #31 from Christoph Michael Becker --- (In reply to Zoltan Herczeg from comment #29) > Ok I will try to do these requests. Will take time. Is ./ a good idea to > create a temporary file? What other projects do btw? I don't

[pcre-dev] [Bug 1749] PCRE-JITted code should be executed from non-writable memory to obey execmem SELinux restriction

https://bugs.exim.org/show_bug.cgi?id=1749 --- Comment #36 from Zoltan Herczeg --- Landed another big patch which adds allocator support for other CPUs except Tile-GX. The good (bad) news is that on-the-fly code modifications are available again regardless of allocator.

[pcre-dev] [Bug 1749] PCRE-JITted code should be executed from non-writable memory to obey execmem SELinux restriction

https://bugs.exim.org/show_bug.cgi?id=1749 --- Comment #34 from Petr Pisar --- glibc documents $TMPDIR, a macro that resolves to /tmp, and /tmp. Working directory isn't probably a good idea. -- You are

[pcre-dev] [Bug 2010] sljitProtExecAllocator temp file descriptor isn't CLOEXEC

https://bugs.exim.org/show_bug.cgi?id=2010 Giuseppe D'Angelo changed: What|Removed |Added CC||dange...@gmail.com ---

[pcre-dev] [Bug 2007] New: Stack Overflow in op_recurse_ovecsave()

https://bugs.exim.org/show_bug.cgi?id=2007 Bug ID: 2007 Summary: Stack Overflow in op_recurse_ovecsave() Product: PCRE Version: N/A Hardware: x86-64 OS: Linux Status: NEW Severity: bug Priority:

[pcre-dev] [Bug 2008] New: [pcre2test] Heap out of bounds read in pchars8()

https://bugs.exim.org/show_bug.cgi?id=2008 Bug ID: 2008 Summary: [pcre2test] Heap out of bounds read in pchars8() Product: PCRE Version: N/A Hardware: x86-64 OS: Linux Status: NEW Severity: bug

[pcre-dev] [Bug 1749] PCRE-JITted code should be executed from non-writable memory to obey execmem SELinux restriction

https://bugs.exim.org/show_bug.cgi?id=1749 --- Comment #35 from Christian Persch (GNOME) --- (In reply to Christoph Michael Becker from comment #31) > (In reply to Zoltan Herczeg from comment #29) > > Ok I will try to do these requests. Will take time. Is ./ a good idea to > >

[pcre-dev] [Bug 2009] New: sljitProtExecAllocator defines _XOPEN_SOURCE too late

https://bugs.exim.org/show_bug.cgi?id=2009 Bug ID: 2009 Summary: sljitProtExecAllocator defines _XOPEN_SOURCE too late Product: PCRE Version: N/A Hardware: All OS: All Status: NEW Severity: bug

[pcre-dev] [Bug 2010] New: sljitProtExecAllocator temp file descriptor isn't CLOEXEC

https://bugs.exim.org/show_bug.cgi?id=2010 Bug ID: 2010 Summary: sljitProtExecAllocator temp file descriptor isn't CLOEXEC Product: PCRE Version: N/A Hardware: x86 OS: Linux Status: NEW

[pcre-dev] [Bug 2009] sljitProtExecAllocator defines _XOPEN_SOURCE too late

https://bugs.exim.org/show_bug.cgi?id=2009 Zoltan Herczeg changed: What|Removed |Added CC||hzmes...@freemail.hu ---

[pcre-dev] [Bug 1749] PCRE-JITted code should be executed from non-writable memory to obey execmem SELinux restriction

https://bugs.exim.org/show_bug.cgi?id=1749 --- Comment #37 from Petr Pisar --- (In reply to Zoltan Herczeg from comment #36) > Landed another big patch which adds allocator support for other CPUs except > Tile-GX. The good (bad) news is that on-the-fly code modifications are >

[pcre-dev] [Bug 1749] PCRE-JITted code should be executed from non-writable memory to obey execmem SELinux restriction

https://bugs.exim.org/show_bug.cgi?id=1749 --- Comment #38 from Zoltan Herczeg --- > All the tests were run without SELinux enforcing. Great news! Thank you very much for testing. > Running the tests with SELinux enforcing W^X pages on all of the platforms > would require

[pcre-dev] [Bug 1749] PCRE-JITted code should be executed from non-writable memory to obey execmem SELinux restriction

https://bugs.exim.org/show_bug.cgi?id=1749 --- Comment #41 from Petr Pisar --- (In reply to Zoltan Herczeg from comment #38) > I would be grateful if you could check the JIT compiler as well on these > systems. > > 1) Please checkout the compiler > > svn checkout

[pcre-dev] [Bug 1749] PCRE-JITted code should be executed from non-writable memory to obey execmem SELinux restriction

https://bugs.exim.org/show_bug.cgi?id=1749 Petr Pisar changed: What|Removed |Added Attachment #959 is|0 |1 obsolete|

[pcre-dev] [Bug 1749] PCRE-JITted code should be executed from non-writable memory to obey execmem SELinux restriction

https://bugs.exim.org/show_bug.cgi?id=1749 --- Comment #23 from Petr Pisar --- No, it does not help. Change to R-- passes, subsequent change to R-X is denied. After reading Linux security/selinux/hooks.c (search for default_noexec variable), I think it simply refuses PROT_EXEC

[pcre-dev] [Bug 1749] PCRE-JITted code should be executed from non-writable memory to obey execmem SELinux restriction

https://bugs.exim.org/show_bug.cgi?id=1749 --- Comment #21 from Petr Pisar --- The error code is visible in the strace output I quoted in the comment #16. Return value is -1 and errno is EACCES. This failure is result of the SELinux policy that not only prevents from having

[pcre-dev] [Bug 1749] PCRE-JITted code should be executed from non-writable memory to obey execmem SELinux restriction

https://bugs.exim.org/show_bug.cgi?id=1749 --- Comment #25 from Petr Pisar --- Created attachment 961 --> https://bugs.exim.org/attachment.cgi?id=961=edit Attempt to propagate mprotect() failure Attached patch tries to handle failed mprotect() call so that an application

[pcre-dev] [Bug 1916] Advanced data processing for an alternation with a lot of key words

https://bugs.exim.org/show_bug.cgi?id=1916 Philip Hazel changed: What|Removed |Added Status|NEW |RESOLVED

[pcre-dev] [Bug 1916] Advanced data processing for an alternation with a lot of key words

https://bugs.exim.org/show_bug.cgi?id=1916 --- Comment #6 from Markus Elfring --- (In reply to Philip Hazel from comment #5) Was the evaluation of regular expressions ever compared for cases as in my example with usages of an approach like “Matching algorithm

[pcre-dev] [Bug 1749] PCRE-JITted code should be executed from non-writable memory to obey execmem SELinux restriction

https://bugs.exim.org/show_bug.cgi?id=1749 --- Comment #26 from Zoltan Herczeg --- Thank you for working on this. However I will probably just drop the current protected allocator implementation since mprotect does not seems the right way to support "security enhanced"

[pcre-dev] [Bug 1916] Advanced data processing for an alternation with a lot of key words

https://bugs.exim.org/show_bug.cgi?id=1916 --- Comment #5 from Philip Hazel --- (In reply to Markus Elfring from comment #4) > (In reply to Philip Hazel from comment #3) > > This kind of feedback is promising. > > * How do you think about to clarify any more improvements

[pcre-dev] [Bug 1916] Advanced data processing for an alternation with a lot of key words

https://bugs.exim.org/show_bug.cgi?id=1916 --- Comment #8 from Markus Elfring --- (In reply to Philip Hazel from comment #7) Have you got any experiences around data structures like prefix tries? -- You are receiving this mail because: You are on the CC list for

[pcre-dev] [Bug 1916] Advanced data processing for an alternation with a lot of key words

https://bugs.exim.org/show_bug.cgi?id=1916 --- Comment #4 from Markus Elfring --- (In reply to Philip Hazel from comment #3) This kind of feedback is promising. * How do you think about to clarify any more improvements around scalability challenges for special

[pcre-dev] [Bug 1916] Advanced data processing for an alternation with a lot of key words

https://bugs.exim.org/show_bug.cgi?id=1916 --- Comment #7 from Philip Hazel --- (In reply to Markus Elfring from comment #6) > (In reply to Philip Hazel from comment #5) > > Was the evaluation of regular expressions ever compared for cases as in my > example with usages

[pcre-dev] [Bug 1916] Advanced data processing for an alternation with a lot of key words

https://bugs.exim.org/show_bug.cgi?id=1916 --- Comment #12 from Markus Elfring --- (In reply to Philip Hazel from comment #11) I would appreciate a bit more background information. http://vcs.pcre.org/pcre2/code/trunk/HACKING?revision=606=markup#l618 * To which

[pcre-dev] [Bug 1916] Advanced data processing for an alternation with a lot of key words

https://bugs.exim.org/show_bug.cgi?id=1916 --- Comment #10 from Markus Elfring --- (In reply to Philip Hazel from comment #9) I am surprised by your answer. I guess that your current regular expression engine organises its data into other structures. I am just

[pcre-dev] [Bug 1916] Advanced data processing for an alternation with a lot of key words

https://bugs.exim.org/show_bug.cgi?id=1916 --- Comment #11 from Philip Hazel --- (In reply to Markus Elfring from comment #10) > > I guess that your current regular expression engine organises its data into > other structures. I am just curious on how good their run time

[pcre-dev] [Bug 1916] Advanced data processing for an alternation with a lot of key words

https://bugs.exim.org/show_bug.cgi?id=1916 --- Comment #9 from Philip Hazel --- (In reply to Markus Elfring from comment #8) > (In reply to Philip Hazel from comment #7) > > Have you got any experiences around data structures like prefix tries? No. -- You are receiving

[pcre-dev] [Bug 1916] Advanced data processing for an alternation with a lot of key words

https://bugs.exim.org/show_bug.cgi?id=1916 --- Comment #15 from Philip Hazel --- (In reply to Markus Elfring from comment #14) > (In reply to Philip Hazel from comment #13) > > Thanks for another constructive feedback. > > * How are the chances to change the mentioned

[pcre-dev] [Bug 1916] Advanced data processing for an alternation with a lot of key words

https://bugs.exim.org/show_bug.cgi?id=1916 --- Comment #16 from Markus Elfring --- (In reply to Philip Hazel from comment #15) I would appreciate if further software design approaches could be considered for better checking of big alternations (or remarkable

[pcre-dev] [Bug 1916] Advanced data processing for an alternation with a lot of key words

https://bugs.exim.org/show_bug.cgi?id=1916 --- Comment #14 from Markus Elfring --- (In reply to Philip Hazel from comment #13) Thanks for another constructive feedback. * How are the chances to change the mentioned software inefficiency in significant ways? *

[pcre-dev] [Bug 1916] Advanced data processing for an alternation with a lot of key words

https://bugs.exim.org/show_bug.cgi?id=1916 --- Comment #13 from Philip Hazel --- (In reply to Markus Elfring from comment #12) > (In reply to Philip Hazel from comment #11) > > I would appreciate a bit more background information. >

[pcre-dev] [Bug 1749] PCRE-JITted code should be executed from non-writable memory to obey execmem SELinux restriction

https://bugs.exim.org/show_bug.cgi?id=1749 --- Comment #16 from Petr Pisar --- I tried the code. It indeed stopped using pages with both PROT_WRITE and PROT_EXEC, but it still does not work with restricting SELinux: mmap(NULL, 788, PROT_READ|PROT_WRITE,

[pcre-dev] [Bug 1749] PCRE-JITted code should be executed from non-writable memory to obey execmem SELinux restriction

https://bugs.exim.org/show_bug.cgi?id=1749 --- Comment #20 from Zoltan Herczeg --- > And it segfaults because mprotect() return value is not checked and it jumps > into a non-executable page. Hm, what is the error code? The command is issued to an area returned by mmap, so

[pcre-dev] [Bug 2067] Undefined references to iswild and init_colour_output when building with mingw

https://bugs.exim.org/show_bug.cgi?id=2067 --- Comment #3 from Tony Kelman --- Okay thanks, will let you know if any issues. What distro do you do most of your development from? It is possible to cross-compile and test with wine. -- You are receiving this mail

[pcre-dev] [Bug 2079] heap based buffer overflow write in pcre2_get_error_message_32

https://bugs.exim.org/show_bug.cgi?id=2079 Philip Hazel changed: What|Removed |Added Status|NEW |RESOLVED

[pcre-dev] [Bug 2086] New: Bug in Regex match rule

https://bugs.exim.org/show_bug.cgi?id=2086 Bug ID: 2086 Summary: Bug in Regex match rule Product: PCRE Version: 8.40 Hardware: x86 OS: Linux Status: NEW Severity: bug Priority: medium

[pcre-dev] [Bug 2086] Bug in Regex match rule

https://bugs.exim.org/show_bug.cgi?id=2086 Philip Hazel changed: What|Removed |Added Status|NEW |RESOLVED

[pcre-dev] [Bug 2087] New: Questionable assignment for “firstcu” in compile_branch()

https://bugs.exim.org/show_bug.cgi?id=2087 Bug ID: 2087 Summary: Questionable assignment for “firstcu” in compile_branch() Product: PCRE Version: 10.23 (PCRE2) Hardware: All OS: All Status:

[pcre-dev] [Bug 2054] invalid memory read in _pcre32_xclass (pcre_xclass.c)

https://bugs.exim.org/show_bug.cgi?id=2054 Petr Pisar changed: What|Removed |Added CC||ppi...@redhat.com

[pcre-dev] [Bug 2052] invalid memory read in match (pcre_exec.c)

https://bugs.exim.org/show_bug.cgi?id=2052 --- Comment #4 from Petr Pisar --- *** Bug 2054 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are on the CC list for the bug. -- ## List details at

[pcre-dev] [Bug 2067] Undefined references to iswild and init_colour_output when building with mingw

https://bugs.exim.org/show_bug.cgi?id=2067 --- Comment #4 from Philip Hazel --- I use Arch Linux (and have close to zero experience in Windows). Perhaps once the current round of development is over - big refactoring of pcre2_match() in progress - I should investigate

[pcre-dev] [Bug 2089] New: There are identical sub-expressions '(1 << ucp_gbL)'

https://bugs.exim.org/show_bug.cgi?id=2089 Bug ID: 2089 Summary: There are identical sub-expressions '(1 << ucp_gbL)' Product: PCRE Version: 10.23 (PCRE2) Hardware: All OS: All Status: NEW Severity: bug

[pcre-dev] [Bug 2088] pointer was utilized before it was verified against nullptr: pcre2_pattern_info.c

https://bugs.exim.org/show_bug.cgi?id=2088 Petr Pisar changed: What|Removed |Added CC||ppi...@redhat.com

[pcre-dev] [Bug 2076] pcre2_callout_enumerate() checks re for NULL too late

https://bugs.exim.org/show_bug.cgi?id=2076 Petr Pisar changed: What|Removed |Added CC||egor...@gmail.com --- Comment

[pcre-dev] [Bug 2088] New: pointer was utilized before it was verified against nullptr: pcre2_pattern_info.c

https://bugs.exim.org/show_bug.cgi?id=2088 Bug ID: 2088 Summary: pointer was utilized before it was verified against nullptr: pcre2_pattern_info.c Product: PCRE Version: 10.23 (PCRE2) Hardware: All OS: All

[pcre-dev] [Bug 2088] pointer was utilized before it was verified against nullptr: pcre2_pattern_info.c

https://bugs.exim.org/show_bug.cgi?id=2088 --- Comment #1 from egoroff --- You should do something like this: #ifdef SUPPORT_UNICODE BOOL utf; #endif if (re == NULL) return PCRE2_ERROR_NULL; #ifdef SUPPORT_UNICODE utf = (re->overall_options & PCRE2_UTF) != 0; #endif --

[pcre-dev] [Bug 2063] [pcre2test] Heap out of bounds read in process_data()

https://bugs.exim.org/show_bug.cgi?id=2063 Philip Hazel changed: What|Removed |Added Resolution|--- |FIXED

[pcre-dev] [Bug 2084] New: C++: Guard 'using std::' directives with namespace pcrecpp

https://bugs.exim.org/show_bug.cgi?id=2084 Bug ID: 2084 Summary: C++: Guard 'using std::' directives with namespace pcrecpp Product: PCRE Version: 8.40 Hardware: All OS: All Status: NEW

[pcre-dev] [Bug 2077] New: pcre2_serialize_decode() can read from invalid memory because it does not know bytes length

https://bugs.exim.org/show_bug.cgi?id=2077 Bug ID: 2077 Summary: pcre2_serialize_decode() can read from invalid memory because it does not know bytes length Product: PCRE Version: 10.23 (PCRE2) Hardware: x86

[pcre-dev] [Bug 2074] New: Files not closed on CMD_LOAD/CMD_SAVE error

https://bugs.exim.org/show_bug.cgi?id=2074 Bug ID: 2074 Summary: Files not closed on CMD_LOAD/CMD_SAVE error Product: PCRE Version: 10.23 (PCRE2) Hardware: x86 OS: Linux Status: NEW Severity: bug

[pcre-dev] [Bug 2075] New: A memory leak when deserialization detects invalid pattern

https://bugs.exim.org/show_bug.cgi?id=2075 Bug ID: 2075 Summary: A memory leak when deserialization detects invalid pattern Product: PCRE Version: 10.23 (PCRE2) Hardware: x86 OS: Linux Status:

[pcre-dev] [Bug 2079] New: heapb based buffer overflow write in pcre2_get_error_message_32

https://bugs.exim.org/show_bug.cgi?id=2079 Bug ID: 2079 Summary: heapb based buffer overflow write in pcre2_get_error_message_32 Product: PCRE Version: 10.23 (PCRE2) Hardware: x86-64 OS: Linux

[pcre-dev] [Bug 2081] left shift in pcre2_jit_compile.c:3886

https://bugs.exim.org/show_bug.cgi?id=2081 --- Comment #1 from Agostino Sarubbo --- (In reply to Agostino Sarubbo from comment #0) > Output: > libpcre2-10.22/work/pcre2-10.22/src/pcre2_jit_compile.c:3886:15: runtime > error: left shift of 251 by 24 places cannot be represented

[pcre-dev] [Bug 2082] New: left shift in pcre2_jit_compile.c:8369

https://bugs.exim.org/show_bug.cgi?id=2082 Bug ID: 2082 Summary: left shift in pcre2_jit_compile.c:8369 Product: PCRE Version: 10.23 (PCRE2) Hardware: x86-64 OS: Linux Status: NEW Severity: security

[pcre-dev] [Bug 2065] global buffer overflow write in decode_modifiers (pcre2test.c)

https://bugs.exim.org/show_bug.cgi?id=2065 Agostino Sarubbo changed: What|Removed |Added Resolution|--- |DUPLICATE

[pcre-dev] [Bug 1915] Global Variable Buffer Overflow in pcre2test

https://bugs.exim.org/show_bug.cgi?id=1915 Agostino Sarubbo changed: What|Removed |Added CC||a...@gentoo.org --- Comment

[pcre-dev] [Bug 2081] New: left shift in pcre2_jit_compile.c:3886

https://bugs.exim.org/show_bug.cgi?id=2081 Bug ID: 2081 Summary: left shift in pcre2_jit_compile.c:3886 Product: PCRE Version: 10.23 (PCRE2) Hardware: x86-64 OS: Linux Status: NEW Severity: security

[pcre-dev] [Bug 2076] New: pcre2_callout_enumerate() checks re for NULL too late

https://bugs.exim.org/show_bug.cgi?id=2076 Bug ID: 2076 Summary: pcre2_callout_enumerate() checks re for NULL too late Product: PCRE Version: 10.23 (PCRE2) Hardware: x86 OS: Linux Status: NEW Severity:

[pcre-dev] [Bug 2094] PCRE 8.40 with JIT mode enabled generates invalid memory read warnings

https://bugs.exim.org/show_bug.cgi?id=2094 Zoltan Herczeg changed: What|Removed |Added CC||hzmes...@freemail.hu ---

[pcre-dev] [Bug 2087] Questionable assignment for “firstcu” in compile_branch()

https://bugs.exim.org/show_bug.cgi?id=2087 --- Comment #2 from egoroff --- Sorry but comment below (not above as i said first) should be taken into account: /* If the character is more than one code unit long, we can set firstcu only if it is not to be matched

[pcre-dev] [Bug 2087] Questionable assignment for “firstcu” in compile_branch()

https://bugs.exim.org/show_bug.cgi?id=2087 egoroff changed: What|Removed |Added CC||egor...@gmail.com --- Comment #1

[pcre-dev] [Bug 2086] Bug in Regex match rule

https://bugs.exim.org/show_bug.cgi?id=2086 --- Comment #3 from Philip Hazel --- I do not like to make releases more frequently than 6-month intervals, because every release makes work for the downstream maintainers. Only if there were a really major bug would I release

[pcre-dev] [Bug 2094] PCRE 8.40 with JIT mode enabled generates invalid memory read warnings

https://bugs.exim.org/show_bug.cgi?id=2094 --- Comment #2 from Datong Sun --- (In reply to Zoltan Herczeg from comment #1) > I think this is a known side effect of the SSE2 optimization in PCRE-JIT. > The optimized algorithm reads aligned 16 byte data packets which might

[pcre-dev] [Bug 2098] The pcre2_general_context type is typo'd as pcre22_general_context in the documentation

https://bugs.exim.org/show_bug.cgi?id=2098 Philip Hazel changed: What|Removed |Added Resolution|--- |FIXED

[pcre-dev] [Bug 2099] [PATCH] Extend pcre2compat.3 to Perl 5.26

https://bugs.exim.org/show_bug.cgi?id=2099 Philip Hazel changed: What|Removed |Added Resolution|--- |FIXED

[pcre-dev] [Bug 2103] While configuring PCRE on Solaris 10, it throws error: "could not determine link -lib interface"

https://bugs.exim.org/show_bug.cgi?id=2103 Nasr changed: What|Removed |Added Resolution|INVALID |FIXED --- Comment #2 from Nasr

[pcre-dev] [Bug 2091] Conditional jump or move depends on uninitialised value at pcretest.c:5364 in UTF-32 mode

https://bugs.exim.org/show_bug.cgi?id=2091 --- Comment #1 from Philip Hazel --- I cannot reproduce this in the latest code. In 8.40 I get a big crash "stack smashing detected", but nothing is reported for the current head code. Some 32-bit bugs have been fixed, so perhaps

[pcre-dev] [Bug 2084] C++: Guard 'using std::' directives with namespace pcrecpp

https://bugs.exim.org/show_bug.cgi?id=2084 Philip Hazel changed: What|Removed |Added Resolution|--- |FIXED

[pcre-dev] [Bug 2087] Questionable assignment for “firstcu” in compile_branch()

https://bugs.exim.org/show_bug.cgi?id=2087 --- Comment #3 from Philip Hazel --- Actually, it is the *first* line that should be removed. It dates from before 32-bit support when the case flag could be in the same variable as the character. Now it is held in a separate

[pcre-dev] [Bug 2089] There are identical sub-expressions '(1 << ucp_gbL)'

https://bugs.exim.org/show_bug.cgi?id=2089 Philip Hazel changed: What|Removed |Added Resolution|--- |FIXED

<    2   3   4   5   6   7   8   9   10   11   >