Bug #78630 [Com]: PHP 7.3 preg_match(): JIT compilation failed: no more memory (need pcre.jit=0)

From: Date: Fri, 04 Oct 2019 15:46:25 +0000
Subject: Bug #78630 [Com]: PHP 7.3 preg_match(): JIT compilation failed: no more memory (need pcre.jit=0)
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-223086@lists.php.net to get a copy of this message 
Edit report at https://bugs.php.net/bug.php?id=78630&edit=1

 ID:                 78630
 Comment by:         ilya at ilya dot pp dot ua
 Reported by:        ilya at ilya dot pp dot ua
 Summary:            PHP 7.3 preg_match(): JIT compilation failed: no
                     more memory (need pcre.jit=0)
 Status:             Open
 Type:               Bug
 Package:            PCRE related
 Operating System:   openSUSE Tumbleweed
 PHP Version:        7.3.10
 Block user comment: N
 Private report:     N

 New Comment:

https://build.opensuse.org/package/view_file/devel:libraries:c_c++/pcre2/pcre2.changes?expand=1
-------------------------------------------------------------------
Tue Dec 11 14:31:55 UTC 2018 - Cristian Rodríguez <crrodriguez@opensuse.org>

- Build with --enable-jit-sealloc option, otherwise when 
  selinux is enabled or systemd memory protections are on,
  programs will fail to work with execmem violations.

Vicious circle. :-(


Previous Comments:
------------------------------------------------------------------------
[2019-10-04 15:24:03] ilya at ilya dot pp dot ua

I'm build pcre2 without "--enable-jit-sealloc" and it works without errors!
https://bugzilla.suse.com/attachment.cgi?id=820598
Please see what has changed, is jit compiled at all, and if so, in which directory?

------------------------------------------------------------------------
[2019-10-04 14:08:38] nikic@php.net

> than that fallback simply happen in pcre itself and for some reason not in pcre2

Actually the fallback does still happen, the difference is just that now a warning is printed. The
preg_match() call succeeds in either case though.

I have now landed an initial improvement in https://github.com/php/php-src/commit/1d6e9da7433bddca5c591ef5b2eeef9c410543bb.
It provides a more explicit error message, pointing people to either fix their security restrictions
or set pcre.jit=0. It also disables the JIT, so this is not going to be printed for every regex like
the current warning is.

We might want to change this to happen completely silently though.

> Does something have to change if I rebuild pcre2 without option
> "--enable-jit-sealloc" and rebuild php with this?

It might work. But if there is some restriction in place that prohibits WX mmaps, then that
won't help either.

------------------------------------------------------------------------
[2019-10-04 13:42:41] ilya at ilya dot pp dot ua

Does something have to change if I rebuild pcre2 without option "--enable-jit-sealloc" and
rebuild php with this?
I am now waiting for the building to complete.

------------------------------------------------------------------------
[2019-10-04 13:28:28] bugreports at gmail dot com

this bugreport here was the reason that i opened https://bugs.php.net/bug.php?id=78631 last night

things like https://bugs.exim.org/show_bug.cgi?id=2453 as
well as the summarized changelog from fedora pcre2-10.33 for me are questioning if cherrypicking
alone scales

------------------------------------------------------------------------
[2019-10-04 13:23:57] bugreports at gmail dot com

than that fallback simply happen in pcre itself and for some reason not in pcre2

mod_security uses pcre_jit too, had an issue some years ago and was forced to rebuild it without to
prevent some specific crashes and it shares the MemoryDenyWriteExecute=yes

> then people may not get good performance, but at least code will work

not sure if that's the best thing to do, i would have preferred a one time startup warning
because in that case while trying out "MemoryDenyWriteExecute=yes" i would have reverted
it which will happen now :-)

------------------------------------------------------------------------


The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at

    https://bugs.php.net/bug.php?id=78630


--
Edit this bug report at https://bugs.php.net/bug.php?id=78630&edit=1

Thread (34 messages)

« previous php.bugs (#223086) next »