php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #73619 Crash or zend_mm_heap_corrupted error in opcache with OwnCloud 7 update
Submitted: 2016-11-28 21:14 UTC Modified: 2016-11-28 21:21 UTC
From: adamw at happyassassin dot net Assigned:
Status: Closed Package: opcache
PHP Version: 7.0.13 OS: Fedora 20
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If this is not your bug, you can add a comment by following this link.
If this is your bug, but you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: adamw at happyassassin dot net
New email:
PHP Version: OS:

 

 [2016-11-28 21:14 UTC] adamw at happyassassin dot net 
Description:
------------
See downstream bug report:

https://bugzilla.redhat.com/show_bug.cgi?id=1398474

SELinux blocks web servers from what it calls 'execmem' actions by default; as I understand it, this means execution of writeable memory, which is considered a potential avenue for exploitation and not to be necessary for well-written code.

With PHP 7.0.13's default configuration, where just-in-time compilation of PCREs is enabled, Fedora 25 systems see a flood of these 'execmem' denials. Disabling the PCRE JIT feature with `pcre.jit=0` makes them go away.

There is some more discussion of this at https://unix.stackexchange.com/questions/287831/how-to-work-out-why-apache-is-attempting-execmem , where several people traced this problem to the PCRE JIT code using gdb and backtraces are available. These seem to run through _pcre_jit_compile / pcre_study / pcre_get_compiled_regex_cache / php_do_pcre_match .

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2016-11-28 21:21 UTC] adamw at happyassassin dot net
-Status: Open +Status: Closed
 [2016-11-28 21:21 UTC] adamw at happyassassin dot net 
I have absolutely no idea how this wound up as a dupe of https://bugs.php.net/bug.php?id=67687 , as I filed it with completely different content. Can only imagine it's some kind of bug to do with using the same password for both bugs.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Tue Apr 23 12:01:31 2024 UTC