Common Vulnerabilities and Exposures assigned an identifier CVE-2011-0753 to the following vulnerability: Name: CVE-2011-0753 URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-0753 Assigned: 20110202 Reference: CONFIRM: http://bugs.php.net/52784 Reference: CONFIRM: http://www.php.net/ChangeLog-5.php Race condition in the PCNTL extension in PHP before 5.3.4, when a user-defined signal handler exists, might allow context-dependent attackers to cause a denial of service (memory corruption) via a large number of concurrent signals. The upstream fix on 5.3.x is here: http://svn.php.net/viewvc/?view=revision&revision=305018 Upstream did not flag this as a security fix. I'm not sure whether we should consider it as such either. PCNTL seems like it would not be used very much (by the docs, it is not recommended to be used in a web environment, so would require a server written in PHP). PCNTL support has existed since 4.3.x, so this may also affect Red Hat Enterprise Linux 4 and 5.
I'll let Joe double check me up on this, but I'm pretty certain this isn't a security flaw. I took a look at the PHP code, and it's clearly wrong, you shouldn't be able to use concurrent signals like this. The fix is easy enough, but it's not a security flaw. If you have permissions to trigger a signal like this, you probably aren't going to be able to cross a trust boundary with this. I'm skeptical the corruption in question could be used for anything outside of a DoS. You can't control the data structure, it's just pointers to the signal handlers.
I agree. Having some kind of trust boundary between a running PHP process and processes which can signal it seems farcical: SIGKILL is a pretty effective way to "deny service". In addition we only support pcntl in the /usr/bin/php command-line build, not in the loadable module for httpd.
I'm closing this not-a-security bug based on the comments above. There's currently no plan to fix this as a security flaw in a security erratum. Statement: Red Hat does not consider this issue to be a security vulnerability since no trust boundary is crossed. Any process able to send signals to a running PHP process can terminate it by sending a carefully-chosen signal.