|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #69833 mcrypt broken in 5.6.10 fd caching not working
Submitted: 2015-06-15 04:40 UTC Modified: 2015-08-17 00:00 UTC
Avg. Score:4.7 ± 0.6
Reproduced:10 of 10 (100.0%)
Same Version:7 (70.0%)
Same OS:2 (20.0%)
From: iand at ekit-inc dot com Assigned: leigh
Status: Closed Package: mcrypt related
PHP Version: 5.6.10 OS: Solaris 9,10
Private report: No CVE-ID:
 [2015-06-15 04:40 UTC] iand at ekit-inc dot com
mcrypt has broken in 5.6.10 on my platform under apache 2.4.12
running with threaded mpm.

$ /opt/local/apache/bin/httpd  -M |grep mpm
 mpm_worker_module (static)

Symptoms are that under apache, php's use of mcrypt runs into time limits...
but if you run the same code from php command line it works fine.

Fatal error: Maximum execution time of 30 seconds exceeded in /opt/local/apache/htdocs/mcr.php on line 7

Inspection with truss shows it is failing to open /dev/urandom

This is a truss from apache 2.4.12 with php 5.6.9:

24686/27:       munmap(0xCD3B0000, 4096)                        = 0
24686/27:       munmap(0xCD390000, 7880)                        = 0
24686/27:       munmap(0xCD3A1000, 5040)                        = 0
24686/27:       munmap(0xCD370000, 2724)                        = 0
24686/27:       munmap(0xCD380000, 3028)                        = 0
24686/27:       open("/dev/urandom", O_RDONLY)                  = 17
24686/27:       read(17, "02F7F1F1 3CA $A8", 8)                 = 8
24686/27:       close(17)                                       = 0
24686/27:       open("/opt/local/lib/libmcrypt/", O_RDONLY) = 17

whereas on apache 2.4.12/php 5.6.10 (below) it keeps reading from fd #0 
(lsof says this is /dev/null)  until the timeout is reached.

25529/27:       munmap(0xCD3B0000, 4096)                        = 0
25529/27:       munmap(0xCD390000, 7880)                        = 0
25529/27:       munmap(0xCD3A1000, 5040)                        = 0
25529/27:       munmap(0xCD370000, 2724)                        = 0
25529/27:       munmap(0xCD380000, 3028)                        = 0
25529/27:       read(0, 0x0853CF78, 8)                          = 0
25529/27:       read(0, 0x0853CF78, 8)                          = 0
25529/27:       read(0, 0x0853CF78, 8)                          = 0
25529/27:       read(0, 0x0853CF78, 8)                          = 0
25529/27:       read(0, 0x0853CF78, 8)                          = 0

Looking at the php change log for 5.6.10 and the related changes in mcrypt.c
it would seem that the changes here have caused this fail.

Looking at these changes, I can spot one obvious error; the close code
doesn't consider fd#0 an open fd.  Patch for this below.  

However I suspect there is something else going on perhaps related to 
the multi-threaded environment.

$ diff -c mcrypt.c.orig mcrypt.c
*** mcrypt.c.orig       Wed Jun 10 07:42:27 2015
--- mcrypt.c    Mon Jun 15 03:33:18 2015
*** 450,461 ****
        php_stream_filter_unregister_factory("mcrypt.*" TSRMLS_CC);
        php_stream_filter_unregister_factory("mdecrypt.*" TSRMLS_CC);
!       if (MCG(fd[RANDOM]) > 0) {
!       if (MCG(fd[URANDOM]) > 0) {
--- 450,463 ----
        php_stream_filter_unregister_factory("mcrypt.*" TSRMLS_CC);
        php_stream_filter_unregister_factory("mdecrypt.*" TSRMLS_CC);
!       if (MCG(fd[RANDOM]) >= 0) {
+               MCG(fd[RANDOM]) = -1;
!       if (MCG(fd[URANDOM]) >= 0) {
+               MCG(fd[URANDOM]) = -1;


So further debugging is required.

Test script:
$plaintext="hello world";

$key = "1;lk23GH2KJ:l*&^$^%$913S";

$encrypted = bin2hex(mcrypt_encrypt(MCRYPT_3DES,$key,$plaintext,MCRYPT_MODE_ECB,mcrypt_create_iv(mcrypt_get_iv_size(MCRYPT_3DES,MCRYPT_MODE_CFB))));

$decrypted_data = trim(mcrypt_decrypt(MCRYPT_3DES,$key,hex2bin($encrypted),MCRYPT_MODE_ECB,mcrypt_create_iv(mcrypt_get_iv_size(MCRYPT_3DES,MCRYPT_MODE_CFB))), "\0");

print "orig=".$plaintext."\n";
print "encr=".$encrypted."\n";
print "decrypted=".$decrypted_data."\n";
if($plaintext != $decrypted_data) {
        print "MISMATCH\n";
else {
        print "MATCH\n";


Expected result:
Instant; no timeout

Actual result:


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2015-06-15 07:11 UTC]
-Assigned To: +Assigned To: leigh
 [2015-06-15 07:11 UTC]
@leigh: Please also check whether this applies to the CSPRNG as well.
 [2015-06-15 08:53 UTC] iand at ekit-inc dot com
Hi Leigh; can you elaborate on how I can test that please.

Ian D
 [2015-06-16 06:16 UTC] compi at stz-bg dot com
Have the same problem on test server Linux Slackware x64 current. Interesting on produce servers are the same like test server (packages) this problem does not exists, but my test server run on apache2, produce servers on nginx with php-fpm.
 [2015-06-22 17:55 UTC] info at regioconnect dot net
Can confirm this problem on debian 7 on xen PV.
apache 2.4.12, both for php 5.5.26 and 5.6.10
underlying distro is debian wheezy, but apache and php were source compiled.

happens with mediawiki 1.25.1:

in includes/MWCryptRand.php
$iv = mcrypt_create_iv( $rem, MCRYPT_DEV_URANDOM );

changing 2nd parameter to MCRYPT_RAND makes the problem go away.
 [2015-08-03 12:43 UTC]
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.
 [2015-08-05 03:23 UTC] 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-06 19:10 UTC]
@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.

 [2015-08-06 20:33 UTC]
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-09 16:56 UTC]
@leigh, ok, i can tell why it is zero now, see;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.

 [2015-08-10 03:23 UTC] 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-10 03:53 UTC] iand at ekit-inc dot com
I'll try the patch mentioned here;a=commitdiff;h=a94ea9c97a5331d416c6256e5b01645188182054   

against 5.6.12
 [2015-08-10 07:37 UTC]
@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.

 [2015-08-11 14:55 UTC]
Automatic comment on behalf of ab
Log: fix bug #69833 mcrypt fd caching not working
 [2015-08-11 14:55 UTC]
-Status: Assigned +Status: Closed
 [2015-08-11 15:04 UTC]
Bakported into 5.6 now, please check.

@leigh btw wasn't it actually an ABI breach adding a new member to the globals struct in PhP5? Maybe with very low risk to be breaching something indeed, but just to mention ;)

 [2015-08-14 18:57 UTC] m at thedigitalmachine dot com
I'm getting the mcrypt timeout problem in mediawiki but I don't think I have the fix yet:

  gentoo linux kernel 4.0.5
  php 5.6.12
  apache 2.2.31
  MPM = event
  mediawiki 1.24.2

I can provide more info if desired.  Sorry if this is noise, I wasn't sure which version of PHP has this fix, I'll keep checking for updates and testing.  Thanks!
 [2015-08-15 15:41 UTC]
@m, the fix is not in any release by this time, but you can check the latest 5.6 branch.

 [2015-08-17 00:00 UTC] iand at ekit-inc dot com
Sorry for the delay; my attempts to build php 5.6.12 have failed so far; so I've
backported the patch and built with 5.6.11 and it appears to fix the problem 
with mcrypt.   I'll call this one closed.  Thanks.
 [2015-08-18 16:24 UTC]
Automatic comment on behalf of ab
Log: fix bug #69833 mcrypt fd caching not working
PHP Copyright © 2001-2017 The PHP Group
All rights reserved.
Last updated: Fri Feb 24 01:01:37 2017 UTC