|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #69472 php_sys_readlink ignores misc errors from GetFinalPathNameByHandleA
Submitted: 2015-04-16 18:15 UTC Modified: 2015-04-23 14:15 UTC
From: jan dot starke at t-systems dot com Assigned: ab (profile)
Status: Closed Package: Filesystem function related
PHP Version: Irrelevant OS: Windows
Private report: No CVE-ID: None
 [2015-04-16 18:15 UTC] jan dot starke at t-systems dot com
The Windows API functions GetFinalPathNameByHandleA, which is used by php_sys_readlink, has two different ways of returning an error:
 (1) the return value is different from cchFilePath (which is MAXPATHLEN in php_sys_readlink). This error is raised if the buffer to store the pathname is not large enough to hold the pathname.
 (2) the return value is zero. This error can be caused by one of ERROR_PATH_NOT_FOUND, ERROR_NOT_ENOUGH_MEMORY or ERROR_INVALID_PARAMETER.

Unfortunately, the second case is not handled by php_sys_readlink. As a result, php_sys_readlink writes an empty string to target and returns 0 as its length, which both is incorrect.

Expected result:
php_sys_readlink should return -1 if GetFinalPathNameByHandleA returns 0:


if (dwRet >= MAXPATHLEN || dwRet == 0) {
  return -1;


Actual result:
if GetFinalPathNameByHandleA returns 0, php_sys_readlink returns 0 :-(

This brakes php_check_specific_open_basedir, which in our case creates some problems


if (dwRet >= MAXPATHLEN) {
  return -1;



0001-fix-69472-return-value-0-by-GetFinalPathNameByHandle.patch (last revision 2015-04-16 19:12 UTC by jan dot starke at outofbed dot org)

Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2015-04-20 08:15 UTC]
-Status: Open +Status: Feedback
 [2015-04-20 08:15 UTC]
Thanks for the patch. Could you please add a test for this case as well (check any of the current *.phpt cases for an example, maybe in ext\standard\tests\file)?

 [2015-04-20 21:02 UTC] jan dot starke at t-systems dot com
Not really. We currently do not know the reason why GetFinalPathNameByHandle returns 0. We host a large number of microsites, but we observe this behaviour only with a very small number of sites. Additionally, this problems seems to be IIS/Fast-CGI related. It did not occur with php.exe until now, only with php-cgi.exe when run within IIS.

To write a test, we must construct a case where GetFinalPathNameByHandle reliably returns 0. As soon as we do not understand the reason for the behaviour of GetFinalPathNameByHandle, we cannot create a working test.

As soon as we know more about the root cause of our specific problem, I will let you know.

BTW; I suppose there is another problem with GetFinalPathNameByHandle itself: We observed that simply renaming one of the folders in open_basedir (and changing the setting accordingly) made the problem go away. Possibly, a better fix was to not use GetFinalPathNameByHandle at all, but switch to  GetFileInformationByHandleEx...

Regards, Jan
 [2015-04-22 08:11 UTC]
-Assigned To: +Assigned To: ab
 [2015-04-22 08:11 UTC]
Thanks for the follow up.

Please explain why the usage of GetFileInformationByHandleEx would be better. From tho doc, both support the same technologies.

Regarding your patch - yeah, you made a good catch. Are you already using the patched version? If so, you could see something interesting in the error logs.

Btw. what kind of shares are used on those hosts?

 [2015-04-23 13:28 UTC] jan dot starke at t-systems dot com
No, we are not using the patched versions. Our policies enforce us to use official releases only. But we have some testing environments where we can test such patches.

However, during our test we did not see something interesting in our logs. Could you give me a hint?

Today, I added some debug code:

	dwRet = pGetFinalPathNameByHandle(hFile, target, MAXPATHLEN, VOLUME_NAME_DOS);
	if (dwRet == 0) {
		FILE* teeshop_fh;
		teeshop_fh = fopen("C:\\Temp\\GetFinalPathNameByHandle.log", "a");
		fprintf(teeshop_fh, "GetFinalPathNameByHandle('%s') returned 0x%08x\n", link, GetLastError());
		return -1;
	if(dwRet >= MAXPATHLEN) {
		return -1;

We observed that GetFinalPathNameByHandle returns 0xb7 (ERROR_ALREADY_EXISTS). Unfortunately, this error should never be raised by this function (according to Microsoft's documentation). I assume this error is returned by NtQueryObject, but I do not really know. Does it make sense to post a bug to Microsoft?

In my eyes it is impossible to create a working testcase, because we cannot reliably create the error context. We should assume that GetFinalPathNameByHandle may return 0 in any case, without knowing the cause.

Regards, Jan
 [2015-04-23 13:46 UTC] jan dot starke at t-systems dot com
In case the error code is returned by NtQueryObject, it would map to STATUS_OBJECT_NAME_COLLISION ...

I don't know why NtQueryObject should return this error code.
 [2015-04-23 14:15 UTC]
Hi Jan,

I guess the ERROR_ALREADY_EXISTS you see comes from the fopen call. GetLastError() needs to be saved straight after the GetFinalPathNameByHandleA() (or in general, after the function of interest). There are also cases where a function doesn't touch the errno, so if not reset it stays from one of the previous calls (but obviously not the case here).

Also, it'd be still interesting whether the files/links involved are on network shares. That could be an additional factor for a reproduce. Maybe you need some more load or break the connectivity on the share.

I think we should apply this patch anyway, but it were still useful to know to investigate. IMHO.

 [2015-04-28 13:29 UTC]
Automatic comment on behalf of
Log: Fixed bug #69472 php_sys_readlink ignores misc errors from GetFinalPathNameByHandleA
 [2015-04-28 13:29 UTC]
-Status: Feedback +Status: Closed
 [2016-07-20 11:38 UTC]
Automatic comment on behalf of
Log: Fixed bug #69472 php_sys_readlink ignores misc errors from GetFinalPathNameByHandleA
PHP Copyright © 2001-2023 The PHP Group
All rights reserved.
Last updated: Sun May 28 15:03:42 2023 UTC