Bug 674705 - (CVE-2011-0753) CVE-2011-0753 php: race condition when handling many concurrent signals may lead to memory corruption
CVE-2011-0753 php: race condition when handling many concurrent signals may l...
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
All Linux
unspecified Severity unspecified
: ---
: ---
Assigned To: Red Hat Product Security
: Security
Depends On:
  Show dependency treegraph
Reported: 2011-02-02 19:08 EST by Vincent Danen
Modified: 2015-08-19 05:03 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2011-02-28 12:06:33 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Vincent Danen 2011-02-02 19:08:00 EST
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:


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.
Comment 1 Josh Bressers 2011-02-16 15:44:40 EST
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.
Comment 2 Joe Orton 2011-02-17 03:53:59 EST
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.
Comment 3 Tomas Hoger 2011-02-28 12:06:33 EST
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.


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.

Note You need to log in before you can comment on or make changes to this bug.