php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #75074 php-process crash when is_file() is used with strings longer 260 chars
Submitted: 2017-08-14 09:13 UTC Modified: 2017-12-05 08:03 UTC
Votes:1
Avg. Score:4.0 ± 0.0
Reproduced:1 of 1 (100.0%)
Same Version:1 (100.0%)
Same OS:0 (0.0%)
From: trpro at gmx dot de Assigned: ab (profile)
Status: Closed Package: Filesystem function related
PHP Version: 7.1.8, 7.1.9, 7.1.10, 7.1.12 OS: Windows 7
Private report: No CVE-ID: None
 [2017-08-14 09:13 UTC] trpro at gmx dot de
Description:
------------
When i check a string if it is a valid path, and the string is longer then 260 chars, the php-process (cgi and cli) will crash.

I use a fresh downloaded php 7.1.8 (VC14 x86 Non Thread Safe (2017-Aug-02 00:22:56)), with the default php.ini from the archive.

cmd: .\php.exe -c .\php.ini-production C:\phptest.php

Operatingsystem: Windows 7 Professional SP1 with all updates installed.

Test script:
---------------
<?php

$data = str_pad("", 261, "x");
is_file($data);


Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2017-08-14 09:41 UTC] daverandom@php.net
I cannot reproduce this on Win 10 x64, tried with php-7.1.8-nts-Win32-VC14-x64, php-7.1.8-nts-Win32-VC14-x86, and php-7.1.8-Win32-VC14-x64.

Please can you double check that you have the x86 VC14 redistributables correctly installed on your system?

Test script:
---------------
C:\Users\chris.wright>d:\temp\php-7.1.8-nts-Win32-VC14-x86\php.exe -c d:\temp\php-7.1.8-nts-Win32-VC14-x86\php.ini-production -r "$data = str_pad('', 461, 'x'); var_dump(is_file($data));"
bool(false)
 [2017-08-14 09:47 UTC] daverandom@php.net
Have now tested with all 4 official release builds on both W7 x64 and W10 x64, cannot reproduce in any configuration.

I don't have any x86 Windows installations handy to test against.
 [2017-08-14 09:48 UTC] daverandom@php.net
-Status: Open +Status: Feedback
 [2017-08-14 12:05 UTC] trpro at gmx dot de
VC14 redistributable x86 is installed correctly.

PHP 7.1.8 NTS x86 is running without problems on my system, but only this one function (is_file) with parameter (length > 260) will fail!

PHP 7.0.22 NTS x86, PHP 7.1.8 NTS x64 and PHP 7.1.8 TS x86, will work fine with the test-script.

We checked the script on my collegues pc and, there is the same error, he also has Win 7 Pro x64.

I downloaded a vm from: https://developer.microsoft.com/en-us/microsoft-edge/tools/vms/ (VM: IE10 Win7 (x86), Plattform: VMware) to test it and the php process will also die in the vm.
On the vm, i only installed visual c++ redist 2015 x86 and downloaded PHP.

Windows gave me the following infos:
<WERReportMetadata>
	<OSVersionInformation>
		<WindowsNTVersion>6.1</WindowsNTVersion>
		<Build>7601 Service Pack 1</Build>
		<Product>(0x30): Windows 7 Professional</Product>
		<Edition>Professional</Edition>
		<BuildString>7601.23714.amd64fre.win7sp1_ldr.170307-1800</BuildString>
		<Revision>1130</Revision>
		<Flavor>Multiprocessor Free</Flavor>
		<Architecture>X64</Architecture>
		<LCID>1031</LCID>
	</OSVersionInformation>
	<ProblemSignatures>
		<EventType>APPCRASH</EventType>
		<Parameter0>php.exe</Parameter0>
		<Parameter1>7.1.8.0</Parameter1>
		<Parameter2>5980eee1</Parameter2>
		<Parameter3>VCRUNTIME140.dll</Parameter3>
		<Parameter4>14.0.24215.1</Parameter4>
		<Parameter5>57bfd587</Parameter5>
		<Parameter6>c0000005</Parameter6>
		<Parameter7>0000d4de</Parameter7>
	</ProblemSignatures>
...
</WERReportMetadata>


This comes from the windows event log:

Faulting application name: php.exe, version: 7.1.8.0, time stamp: 0x5980eee1
Faulting module name: VCRUNTIME140.dll, version: 14.0.24215.1, time stamp: 0x57bfd587
Exception code: 0xc0000005
Fault offset: 0x0000d4de
Faulting process id: 0x3320
Faulting application start time: 0x01d314ee83915ac3
Faulting application path: c:\Temp\PHP 7.1.8 NTS x86\php.exe
Faulting module path: C:\Windows\system32\VCRUNTIME140.dll
Report Id: c27563d3-80e1-11e7-aa2e-f0d5bfcc86ce
 [2017-08-14 13:14 UTC] ab@php.net
Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://bugs.php.net/bugs-generating-backtrace.php for *NIX and
http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32

Once you have generated a backtrace, please submit it to this bug
report and change the status back to "Open". Thank you for helping
us make PHP better.

No reproduce on my side as well, checked on win10 and win7. Maybe there'll be more info if you could supply a dump or at least a backtrace.

Thanks.
 [2017-08-15 10:17 UTC] trpro at gmx dot de
-Status: Feedback +Status: Open
 [2017-08-15 10:17 UTC] trpro at gmx dot de
This is the report from my local pc:

In php__PID__188__Date__08_15_2017__Time_08_53_35AM__162__Second_Chance_Exception_C0000005.dmp the assembly instruction at VCRUNTIME140!memmove+4e in C:\Windows\System32\VCRUNTIME140.dll from Microsoft Corporation has caused an access violation exception (0xC0000005) when trying to read from memory location 0x04840000 on thread 0

Thread 0 - System ID 10672

Entry point   php!php_cli_get_shell_callbacks+500 
Create time   15.08.2017 08:53:33 
Time spent in user mode   0 Days 00:00:00.015 
Time spent in kernel mode   0 Days 00:00:00.015 

This thread is not fully resolved and may or may not be a problem. Further analysis of these threads may be required.

VCRUNTIME140!memmove+4e 
php7!libiconv_set_relocation_prefix+950 
php7!php_stream_stat_path+e6 



This is the report from my test VM:

Thread 0 - System ID 1372

Entry point   php!php_cli_get_shell_callbacks+500 
Create time   15.08.2017 08:57:12 
Time spent in user mode   0 Days 00:00:00.000 
Time spent in kernel mode   0 Days 00:00:00.015 

This thread is not fully resolved and may or may not be a problem. Further analysis of these threads may be required.

VCRUNTIME140!memmove+250
php7!php_stream_stat_path+e6
 [2017-08-21 09:12 UTC] ab@php.net
-Status: Open +Status: Feedback
 [2017-08-21 09:12 UTC] ab@php.net
Thanks for the BT. I still stuck reproducing this, neither with an older 7.2 binary nor with just freshly compiled one :( Were you using the debug symbols? Also maybe you could try some latest snapshot or beta3.

Thanks.
 [2017-09-25 13:07 UTC] steve dot eidemiller at gmail dot com
Appcrash with is_file() string parameter > 260 characters.

This happened to me as well, and it seems repeatable at the moment. Adding my BT here in case it helps. Also, my environment is different: Windows Server 2012 R2 Build 9600 x64 with PHP 7.1.8 CLI NTS MSVC14 x64.

The test script above did not trigger the exception for me. I found the issue with a batch that takes several minutes to run, and triggers the exception every time at the same place. However, capturing the offending 260+ character string from that process won't trigger the exception outside of that long process. And, of course, truncating the same offending string to 260 characters inside the process fixes the issue. I'll continue to troubleshoot, but for me it seems related to other state information within the process.

My BT is as follows:
Thread 0 - System ID 4668
Entry point   php!php_cli_get_shell_callbacks+5f0 
Create time   9/22/2017 2:58:43 PM 
Time spent in user mode   0 Days 00:00:13.187 
Time spent in kernel mode   0 Days 00:00:00.781 
This thread is not fully resolved and may or may not be a problem. Further analysis of these threads may be required.
VCRUNTIME140!MoveSmall+1f0 
php7!libiconv_set_relocation_prefix+1928 
php7!php_stream_stat_path+10a 
php7!php_stat+10b 
php7!php_fputcsv+2215 
php7!php_pdo_free_statement+b820 
php7!execute_ex+157 
php7!zend_execute+159 
php7!zend_execute_scripts+119 
php7!libiconv_set_relocation_prefix+3443b 
php+1e2d 
php+1509 
php!php_cli_get_shell_callbacks+589 
kernel32!BaseThreadInitThunk+d 
ntdll!RtlUserThreadStart+34 

VCRUNTIME140!MOVESMALL+1F0 In php__PID__5060__Date__09_22_2017__Time_03_05_37PM__264__Second_Chance_Exception_C0000005.dmp the assembly instruction at VCRUNTIME140!MoveSmall+1f0 in C:\Windows\System32\VCRUNTIME140.dll from Microsoft Corporation has caused an access violation exception (0xC0000005) when trying to read from memory location 0x0ce6b000 on thread 0

I may be able to get a compiler installed on the server if there's any other useful information that we could get from it.
 [2017-09-28 11:57 UTC] ab@php.net
@steve dot eidemiller at gmail dot com i've tried x86 and x64 on win7 and server 2012r2, but without luck. If you could extract a piece of code to reproduce it, it would be great. Maybe also you could play with it on other machines, with other locale, etc. which could help to figure out the difference. Also, 7.1.10 is getting released now, so worth to try as well.

Thanks.
 [2017-09-28 11:58 UTC] ab@php.net
-Assigned To: +Assigned To: ab
 [2017-09-28 12:45 UTC] trpro at gmx dot de
-Status: Feedback +Status: Assigned -PHP Version: 7.1.8 +PHP Version: 7.1.8, 7.1.9, 7.1.10
 [2017-09-28 12:45 UTC] trpro at gmx dot de
I used the debug symbols, as described in https://bugs.php.net/bugs-generating-backtrace-win32.php.

The crash only occurs with the "PHP 7.1.x x86 NTS"-Binarys from http://windows.php.net/download#php-7.1.

If i used a self compiled PHP 7.1.8, the app will not crash (but i used a differend configuration).

I still can reproduce this behaivor on several machines (All of them with Win7 64bit, latest updates, Intel i5).
 [2017-09-28 13:19 UTC] ab@php.net
@trpro at gmx dot de if you can debug there, please do. Sadly, no VM i've tried brought a crash. It might be good a certain environment triggers it, or a pecific INI.

Thanks.
 [2017-11-28 09:13 UTC] ab@php.net
-Status: Assigned +Status: Feedback
 [2017-11-28 09:13 UTC] ab@php.net
Please check the latest snapshot builds, some fixes was put into 7.1+ dev. Thanks.
 [2017-11-28 10:02 UTC] trpro at gmx dot de
-Status: Feedback +Status: Assigned -PHP Version: 7.1.8, 7.1.9, 7.1.10 +PHP Version: 7.1.8, 7.1.9, 7.1.10, 7.1.12
 [2017-11-28 10:02 UTC] trpro at gmx dot de
With the lastest build (Rev. ree9e32c, x86, NTS) the bug doesn't seem to occur anymore on my testsystem.
 [2017-11-28 10:02 UTC] trpro at gmx dot de
With the lastest build (Rev. ree9e32c, x86, NTS) the bug doesn't seem to occur anymore on my testsystem.
 [2017-12-05 08:03 UTC] ab@php.net
-Status: Assigned +Status: Closed
 [2017-12-05 08:03 UTC] ab@php.net
Many thanks for the checks, closing then. The fix should be present in 7.1+ RCs this week.

Thanks.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Mon Oct 14 05:01:28 2024 UTC