Bug #69833 [Asn]: mcrypt broken in 5.6.10 fd caching not working

Edit report at https://bugs.php.net/bug.php?id=69833&edit=1 ID: 69833 User updated by: iand at ekit-inc dot com 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: 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 Previous Comments: ------------------------------------------------------------------------ [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. ------------------------------------------------------------------------ [2015-08-05 03:23:04] tbmstechnical at gmail dot com Im seeing this issue on php 5.6.11 under apache 2.4.16 with mpm_event_module on Ubuntu 14.04. ------------------------------------------------------------------------ [2015-08-03 12:43:52] leigh@php.net Hi, sorry for the late reply. Yes this affected the CSPRNG fd cache too. Submittd PRs 1450 and 1451 to address MCrypt and random_* respectively to address the fact that the fd can be zero. How it got to be zero is more of a mystery, those read() calls are returning 0 so it looks like it really was /dev/null in Ians trace. ------------------------------------------------------------------------ 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