Hello? Anybody? I the original bug report, and on internals, we now have several positive reproducers for this issue. I worked on a fix, also see the original report.

From everything I understand so far:

EVERY apache2handler based Apache 2.4 ON THIS PLANET CAN BE MADE TO DUMP CORE or worse, AT WILL, WITH AN EASY DOUBLE-HTTP/1.1 REQUEST.

I will continue to work on my patch in the original report, without stressing the security implications too much; tomorrow I'll see that I can run my patched 5.6.7RC1 with our full production load, and will give feedback then.

Apart from that, I cannot invest much more time on this, especially without further guidance regarding several use case issues I don't understand with the current handler code.

Please also refer to these two internals list threads regarding discussion, reproductions, and open questions and issues:

        SAPI apache2handler + pipelined HTTP request core dumps
and, started today on a related topic
        PHP apache2handler virtual() function

Please tell, how would you like to proceed with this issue?

Looks like the core issue is 68486, so I propose to keep the discussion there. It sounds like 2.4 subtly broke its own API without letting people know, but I guess we have to deal with it anyway. Unfortunately, I don't know apache2 internals enough to quickly evaluate this patch, so it probably will have to wait for the next release round, but I'll send a ping to people that may know more on it, and try to look into it a bit later.

Hi stas,

Apache 2.4 "broke" its API in the sense that the r->pool cleanup now happens asynchronously with request processing - sending of reply data to the client runs in parallel with processing the next request (of a HTTP/1.1 pipelined connection, at least), with the first request's r->pool cleanup only being called once all pending data has been sent to the client.

In https://bugs.php.net/bug.php?id=68486 gmoniker proposed a one-line fix to this, which appears to work in first testing. I'm giving it a workout on one of my production servers now, no coredumps during the first 10 minutes. I'll let that run for another 4 hours, and when it stays stable I'll add the one-line fix as a patch comment to the original ticket.

One-line patch for the issue is now attached to the original bug report. Production test with both apache 2.2 and 2.4 (prefork) has been running without any issues, since yesterday afternoon.

Stas, can you please take over getting this released? Maybe it would be good to make a CVE / some kind of advisory, once the fix is release, so people who have this deployed on apache 2.4 know they should upgrade?

Does this patch work fine with virtual(), etc., esp. when virtual also calls PHP? Previous one had compatibility issues with that as I understand.

The one-liner patch fixes the remotely triggerable apache 2.4 http/1.1 pipelined connection segmentation fault.

virtual() is broken regardless of apache version, leading to a segmentation violation when reentering PHP. I verified this with apache 2.4 and 2.2 with PHP 5.6.7RC1, and just tested too with an old PHP 5.5.18 build under apache 2.2 - always segfaults.

That virtual() issue is clearly separate. I will keep investigating that a bit, and to that end open a new bug ticket - but as it seems to be a very old issue, and is not triggerable arbitrarily-remotely, I don't think it should be mixed with the fixing of bug 68486

The fix for this bug has been committed.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.

 For Windows:

http://windows.php.net/snapshots/
 
Thank you for the report, and for helping us make PHP better.