Edit report at https://bugs.php.net/bug.php?id=69833&edit=1
ID: 69833
Updated by: ab@php.net
Reported by: iand at ekit-inc dot com
Summary: mcrypt broken in 5.6.10 fd caching not working
Status: Assigned
Type: Bug
Package: mcrypt related
Operating System: Solaris 9,10
PHP Version: 5.6.10
Assigned To: leigh
Block user comment: N
Private report: N
New Comment:
@iand, you can just check with the current master, it's already in there. If it's ok, it
can be backported into 5.6 branch.
Thanks.
Previous Comments:
------------------------------------------------------------------------
[2015-08-10 03:53:49] iand at ekit-inc dot com
I'll try the patch mentioned here
http://git.php.net/?p=php-src.git;a=commitdiff;h=a94ea9c97a5331d416c6256e5b01645188182054
against 5.6.12
------------------------------------------------------------------------
[2015-08-10 03:23:41] iand at ekit-inc dot com
My patch doesn't fix the reported problem; it was just on observation
that it could fix some other case where fd was 0.
I did some debugging a few weeks back but was unable to identify
what was going on; I strongly suspect there is some thread unsafe
code here and extra locking may be required for the threaded apache's.
For my own use I simply reversed the changes there were made in 5.6.10
so I'm running the 5.6.9 version of mcrypt.c happily in 5.6.11
------------------------------------------------------------------------
[2015-08-09 16:56:10] ab@php.net
@leigh, ok, i can tell why it is zero now, see http://git.php.net/?p=php-src.git;a=commitdiff;h=a94ea9c97a5331d416c6256e5b01645188182054
. I was already wondering as it's already at the first request. @iand, please give the patch a
try with php7.
Normally system could reuse stdin if ulimit was reached or it was explicitly closed. But merely it
seems globals was never properly initialized if ZTS mode. So zero is just an unitialized value, not
something open() has delivered. What is left for this ticket were
- backport to 5.6
- for 7 - integrate the static tsrmls cache
@leigh, let me know if you want to take that over (as it's still assigned to you). I think
CSPRNG part sohuldn't be applied, there the globals are handled correctly, so zero it could be
only in some exceptional case i've mentioned above. Instead there should be some conditions to
avoid a dead loop in both mcrypt and CSPRNG.
Thanks.
------------------------------------------------------------------------
[2015-08-06 20:33:34] leigh@php.net
I wasn't 100% confident the patch would fix the issue, however it does mean we correctly
account for the documented behaviour of open().
I'm not even sure how the issue happens in the first place.
------------------------------------------------------------------------
[2015-08-06 19:10:55] ab@php.net
@iand, @leigh at the first glance the patch doesn't fix the issue in ext/mcrypt. While
it's correct to reset the fd after close, MSHUTDOWN doesn't feel like a place fixing it.
Does it fix the issue for you?
The CSPRNG part looks correct however. Whereby the stuff in the php_random_bytes within if (fd <
0) could be moved into RINIT or even to MINIT, but that's another question.
Thanks.
------------------------------------------------------------------------
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=69833
--
Edit this bug report at https://bugs.php.net/bug.php?id=69833&edit=1