https://bz.apache.org/bugzilla/show_bug.cgi?id=66119
--- Comment #8 from Yann Ylavic <ylavic....@gmail.com> --- Created attachment 38318 --> https://bz.apache.org/bugzilla/attachment.cgi?id=38318&action=edit Honor nmatch for the vector passed to pcre_exec() Since 2.4.52 (r1898467) we always provide a cached (per-thread) buffer to pcre_exec() for the capturing groups, even though the caller does not care about them (by passing nmatch=0, which is the case of <Location> when there are no named captures). The difference is that PCRE1 treats all capturing groups as non-capturing if it's not given a vector to store the offsets, which allows for optimizations and notably less recursion (replaced by tail calls) in some cases. And the regex "^((?!/errors/).)*$" typically falls into this case where discarding/avoiding captures also avoids lot of recursion in pcre_exec() thus stack exhaustion (the crash hit here). This does not depend on the MPM, I could reproduce the crash with prefork by using a longer path. I think the correct thing to do is something like this patch which honors the "nmatch" passed by the caller as for the vector passed to PCRE1 (like before 2.4.52, with a caveat about back-references, see comment in patch), meaning no/NULL vector eventually if the caller does not care. This fixes the <Location ~ "^((?!/errors/).)*$"> case for me (and all the similar {location,directory,file,proxy,..}_walk() cases when nmatch=0 can be used) but there is nothing we can do at httpd level to prevent some (badly written) regexes from exhausting the stack in all cases, notably when captures are to be used like in the RedirectMatch case (bug 66021) or in mod_rewrite most likely. Anyway, Krystian could you test this patch for you case please? -- You are receiving this mail because: You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
