php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #71273 A wrong ext directory setup in php.ini leads to crash
Submitted: 2016-01-04 09:53 UTC Modified: 2016-01-04 21:23 UTC
From: tlegall at easycom-aura dot com Assigned: ab (profile)
Status: Closed Package: Reproducible crash
PHP Version: 7.0.1 OS: Windows
Private report: No CVE-ID: None
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: tlegall at easycom-aura dot com
New email:
PHP Version: OS:

 

 [2016-01-04 09:53 UTC] tlegall at easycom-aura dot com
Description:
------------
A wrongly configured extension_dir in the php.ini leads to a crash of apache, without any error message.
I am using the latest 7.0.1 version from http://windows.php.net/, thread safe x86.


Test script:
---------------
Here is the line of the php.ini causing problems (missing : after the drive name)

; Directory in which the loadable extensions (modules) reside.
; http://php.net/extension-dir
; extension_dir = "./"
; On windows:
extension_dir = "c/wamp/bin/php/php7.0.1/ext"

Expected result:
----------------
Should log a warning indicating that the extensions cannot be found

Actual result:
--------------
Crash at the line 728 of main/main.c
The problem seems to come from the following code snippet, lines 724 - 729:

if (PG(html_errors)) {
		replace_buffer = php_escape_html_entities((unsigned char*)buffer, buffer_len, 0, ENT_COMPAT, NULL);
		efree(buffer);
		buffer = ZSTR_VAL(replace_buffer);
		buffer_len = (int)ZSTR_LEN(replace_buffer);
	}

replace_buffer is null, which leads to the crash of the ZSTR_LEN function.

Backtrace:
>
	php7ts.dll!php_verror(const char * docref, const char * params, int type, const char * format, char * args) Ligne 728	C
 	php7ts.dll!php_error_docref0(const char * docref, int type, const char * format, ...) Ligne 896	C
 	php7ts.dll!php_load_extension(char * filename, int type, int start_now) Ligne 137	C
 	php7ts.dll!php_load_php_extension_cb(void * arg) Ligne 344	C
 	php7ts.dll!php_ini_register_extensions() Ligne 739	C
 	php7apache2_4.dll!php_apache_server_startup(apr_pool_t * pconf, apr_pool_t * plog, apr_pool_t * ptemp, server_rec * s) Ligne 465	C




Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2016-01-04 11:45 UTC] laruence@php.net
-Assigned To: +Assigned To: ab
 [2016-01-04 11:45 UTC] laruence@php.net
can not reproduce on Linux, @welting could you please have a look into this?
 [2016-01-04 13:35 UTC] ab@php.net
@tlegall i'm not repro it as well with just setting extension_dir=c/... Could you maybe post your full php.ini, maybe there's something else is involved?

Another question - which Apache builds do you use? Are they done VC14?

Thanks.
 [2016-01-04 13:45 UTC] tlegall at easycom-aura dot com
I am using apache 2.4.9 built with VC11.
Another thing that might be relevant, is that my system is in French, therefore the message for missing module contains the é character. Here is the actual content of the buffer variable:

Unable to load dynamic library 'c/wamp/bin/php/php7.0.1/ext\php_Easycom7_0_0.dll' - Le module spécifié est introuvable.

I'll try with a VC14 apache
 [2016-01-04 14:16 UTC] ab@php.net
@tlegall yeah, except you build php yourself with VC11, a VC14 Apache build is required. You can grab one from apachelounge.com fe.

Generally PHP7 is built and tested with VC14, VC11 should not be used (and not sure it'll work already).

Thanks.
 [2016-01-04 15:26 UTC] tlegall at easycom-aura dot com
I didn't build php myself with VC11, I am using PHP 7.0.1 VC14 binary from windows.php.net but I was using an apache 2.4.9 VC11 from www.wampserver.com

I just tried with a Apache 2.4.18 VC14 binary from apache loudge and I am experiencing the same issue.

As I said previously, it's most likely related to my system being in french.
Using the debugger, I modified the error message replacing é characters by e and it went thru. It looks like a bug in the php_escape_html_entities function.
 [2016-01-04 21:23 UTC] ab@php.net
-Status: Assigned +Status: Verified
 [2016-01-04 21:23 UTC] ab@php.net
Thanks for the check. I haven't tested on Linux yet, but I guess it'll have the same issue when putting the 0xe9 into the extension_dir= or extension= INI directive. That's the direction to dig. Probably ENT_HTML_SUBSTITUTE_ERRORS flag or alike has to be added, but a NULL check for sure. Have to check on both platforms yet.

With VC11 vs VC14 - it is not the case here, but in general mixing CRT can deliver any possible weird bugs. Please avoid it and continue using both Apache and PHP built with same Visual Studio version.

Thanks.
 [2016-01-05 18:22 UTC] ab@php.net
Automatic comment on behalf of ab
Revision: http://git.php.net/?p=php-src.git;a=commit;h=9a07245b728714de09361ea16b9c6fcf70cb5685
Log: Fixed bug #71273 A wrong ext directory setup in php.ini leads to crash
 [2016-01-05 18:22 UTC] ab@php.net
-Status: Verified +Status: Closed
 [2016-07-20 11:34 UTC] davey@php.net
Automatic comment on behalf of ab
Revision: http://git.php.net/?p=php-src.git;a=commit;h=9a07245b728714de09361ea16b9c6fcf70cb5685
Log: Fixed bug #71273 A wrong ext directory setup in php.ini leads to crash
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Thu Nov 21 12:01:29 2024 UTC