[pcre-dev] [Bug 1991] PCRE2 10.23-RC1 - Stack overflow in internal_dfa_match()
https://bugs.exim.org/show_bug.cgi?id=1991 --- Comment #4 from Philip Hazel --- In fact, I have already added a limiting facility to pcre2_dfa_match(). Change 36 of release 10.23 reads thus: "The pcre2_dfa_match() function now takes note of the recursion limit for the internal recursive calls that are used for lookrounds and recursions within the pattern." I'm sorry that I did not remember to add a comment to this issue to say what had been done. -- You are receiving this mail because: You are on the CC list for the bug. -- ## List details at https://lists.exim.org/mailman/listinfo/pcre-dev
[pcre-dev] [Bug 1991] PCRE2 10.23-RC1 - Stack overflow in internal_dfa_match()
https://bugs.exim.org/show_bug.cgi?id=1991 --- Comment #3 from Kamil Frankowicz --- Created attachment 1013 --> https://bugs.exim.org/attachment.cgi?id=1013&action=edit Smaller POC to trigger stack overflow (pcre2test) -- You are receiving this mail because: You are on the CC list for the bug. -- ## List details at https://lists.exim.org/mailman/listinfo/pcre-dev
[pcre-dev] [Bug 1991] PCRE2 10.23-RC1 - Stack overflow in internal_dfa_match()
https://bugs.exim.org/show_bug.cgi?id=1991 --- Comment #2 from Kamil Frankowicz --- (In reply to Philip Hazel from comment #1) > This is caused by a complicated regex with many nested parentheses. > Compiling such a pattern uses a lot of stack (especially when ASAN is > enabled; this increases stack usage). On my Linux box, compiling runs out of > stack with a 1Mb stack. With a larger stack, a different pattern runs out of > stack while matching (again, much more stack is needed for ASAN). There is > no problem with ASAN on my system if the stack is 4Mb or above. (And as I > keep grumbling, why do people run with such small stacks in these days of > gigabyte memories?) > > PCRE2 does not of itself guard against stack overflows. There are facilities > in PCRE2 for limiting the depth of parentheses in order to prevent stack > overrun when compiling. See the pcre2_set_parens_nest_limit() function. > There are facilities for limiting stack usage in pcre2_match(), but not at > present in pcre2_dfa_match(), which is where your matching stack overrun > happens (though not unless ASAN is in use). > > I will think about adding some limiting features for pcre2_dfa_match(). > Meanwhile, this specific issue is not a valid bug. I triggered this stack overflow on revision 760 (with ASAN) with much smaller payload (243 bytes versus 100 kilobytes). Please consider reopening this issue and adding limiting features in internal_dfa_match(). -- You are receiving this mail because: You are on the CC list for the bug. -- ## List details at https://lists.exim.org/mailman/listinfo/pcre-dev
[pcre-dev] [Bug 1991] PCRE2 10.23-RC1 - Stack overflow in internal_dfa_match()
https://bugs.exim.org/show_bug.cgi?id=1991 Philip Hazel changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #1 from Philip Hazel --- This is caused by a complicated regex with many nested parentheses. Compiling such a pattern uses a lot of stack (especially when ASAN is enabled; this increases stack usage). On my Linux box, compiling runs out of stack with a 1Mb stack. With a larger stack, a different pattern runs out of stack while matching (again, much more stack is needed for ASAN). There is no problem with ASAN on my system if the stack is 4Mb or above. (And as I keep grumbling, why do people run with such small stacks in these days of gigabyte memories?) PCRE2 does not of itself guard against stack overflows. There are facilities in PCRE2 for limiting the depth of parentheses in order to prevent stack overrun when compiling. See the pcre2_set_parens_nest_limit() function. There are facilities for limiting stack usage in pcre2_match(), but not at present in pcre2_dfa_match(), which is where your matching stack overrun happens (though not unless ASAN is in use). I will think about adding some limiting features for pcre2_dfa_match(). Meanwhile, this specific issue is not a valid bug. -- You are receiving this mail because: You are on the CC list for the bug. -- ## List details at https://lists.exim.org/mailman/listinfo/pcre-dev
