Bug #69322 [Fbk->Asn]: LimitRequestBody excession not handled correctly

Edit report at https://bugs.php.net/bug.php?id=69322&edit=1 ID: 69322 User updated by: gmoniker at gmail dot com Reported by: gmoniker at gmail dot com Summary: LimitRequestBody excession not handled correctly -Status: Feedback +Status: Assigned Type: Bug Package: Apache2 related -Operating System: Ubuntu 14.04 +Operating System: Ubuntu 20.04 -PHP Version: 5.6.7 +PHP Version: 7.4.3 Assigned To: cmb Block user comment: N Private report: N New Comment: I have done some testing with PHP 7.4 on Ubuntu 20 and Apache SAPI PHP module. The segfaulting Apache problem has gone away apparently, couldn't reproduce that. So having a PHP errordocument for status 413 Entity Too Large is no longer relevant. The possibly problematic behaviour occurs when the Apache LimitRequestBody size is below the PHP max_post_size setting. When an incoming POST has a size above LimitRequestBody but under max_post_size, then the called PHP script just runs but with empty POST and FILES globals, but with incoming CONTENT_LENGTH set to the original POST size. When the incoming POST size is above the PHP max_post_size, then the script does not run. If you compare this with the Apache static html handler, then that only serves the setup 413 errordocument when a POST exceeds a LimitRequestBody and not the called html file. Previous Comments: ------------------------------------------------------------------------ [2021-10-07 11:39:19] cmb@php.net Is this still an issue with any of the actively supported PHP versions[1]? [1] <https://www.php.net/supported-versions.php> ------------------------------------------------------------------------ [2015-03-28 22:56:23] gmoniker at gmail dot com Description: ------------ If you set a LimitRequestBody in the Apache configuration there are unexpected results with the apache2 PHP module. Expected: an excession of the LimitRequestBody should cancel the entire handling of a PHP request. The script called should not run, and thus produce no output. A PHP script configured to handle a 413 Error should not accept the request body but be fully functional otherwise. There are up to four parameters to this bug: 1. The original handler in use (The one Apache selects or first accepts for handling the URI requested by the client.) 2. The ErrorDocument for 413. (Is it PHP or not) 3. The Apache version. 4. Whether the request is the first to PHP on a worker. In Apache 2.2 (with PHP 5.3.10): When you call a static html file handled by the core module, there is only the output of the 413 ErrorDocument. Using PHP for the ErrorDocument works correctly. When you call a PHP script, you get first the output of the ErrorDocument and then the output of the original PHP script. Using PHP for the ErrorDocument works correctly. In Apache 2.4 (with PHP 5.5.9) When you call a static html file handled by the core module, there is only the output of the 413 ErrorDocument. Using PHP for the ErrorDocument works correctly. When you call a PHP script, you get first the output of the ErrorDocument and then the output of the original PHP script. If you call this as the very first PHP call on a worker, the worker crashes with segfault. All tests done with apache prefork mpm and opcache off on 64-bit system. Test script: --------------- Needed: Apache with prefork mpm, PHP module for Apache, curl, 64-bit system. For 32-bit system results unknown. Set in Apache config: LimitRequestBody 1000 ErrorDocument 413 "/error413.php" In PHP config for Apache: disable opcache ;zend_extension=opcache.so Put a PHP script posterror.php with some output, an error413.php script with some output, and index.html in a suitable documentroot. Stop pre-running Apache webserver Start Apache in different terminal: apache2ctl -X printf '%*s' 2000 | sed 's/ /-/g' > body.txt curl -si -F "post=@body.txt;filename=body.txt" http://localhost/posterror.php curl -si -F "post=@body.txt;filename=body.txt" http://localhost/index.html Expected result: ---------------- When Apache intercepts the call to a script with a 413 error, I expect the PHP script not to run and thus produce no output, only the output of the ErrorDocument if it exists together with a 413 Request Entity Too Large response status. In the case of Apache 2.4, I do not expect a difference between the first call to PHP on a running Apache worker and subsequent calls. Actual result: -------------- Backtrace for segfault on first request to Apache 2.4 with a PHP script and a PHP ErrorDocument for 413: Program received signal SIGSEGV, Segmentation fault. 0x00007ffff3a086cc in php_session_rfc1867_callback (event=5, event_data=0x7fffffffc700, extra=0x7fffffffc5d0) at /root/php5-5.5.9+dfsg/ext/session/session.c:2747 2747 if (Z_TYPE(progress->sid) && progress->key.c) { (gdb) bt #0 0x00007ffff3a086cc in php_session_rfc1867_callback (event=5, event_data=0x7fffffffc700, extra=0x7fffffffc5d0) at /root/php5-5.5.9+dfsg/ext/session/session.c:2747 #1 0x00007ffff3b8df6e in rfc1867_post_handler (content_type_dup=0x7ffff7f26ff8 "\252~M\353R\006", arg=0x7ffff7f29680) at /root/php5-5.5.9+dfsg/main/rfc1867.c:1260 #2 0x00007ffff3b88b73 in sapi_handle_post (arg=0x7ffff7f29680) at /root/php5-5.5.9+dfsg/main/SAPI.c:189 #3 0x00007ffff3b90217 in php_default_treat_data (arg=0, str=0x0, destArray=0x0) at /root/php5-5.5.9+dfsg/main/php_variables.c:322 #4 0x00007ffff39a1a48 in mbstr_treat_data (arg=0, str=0x0, destArray=0x0) at /root/php5-5.5.9+dfsg/ext/mbstring/mb_gpc.c:69 #5 0x00007ffff3b913e2 in php_auto_globals_create_post (name=0x7ffff13474a0 "_POST", name_len=5) at /root/php5-5.5.9+dfsg/main/php_variables.c:665 #6 0x00007ffff3bf3d68 in zend_auto_global_init (auto_global=0x555555818480) at /root/php5-5.5.9+dfsg/Zend/zend_compile.c:6724 #7 0x00007ffff3c1f728 in zend_hash_apply (ht=0x555555803d80, apply_func=0x7ffff3bf3d1c <zend_auto_global_init>) at /root/php5-5.5.9+dfsg/Zend/zend_hash.c:716 #8 0x00007ffff3bf3da1 in zend_activate_auto_globals () at /root/php5-5.5.9+dfsg/Zend/zend_compile.c:6734 #9 0x00007ffff3b91179 in php_hash_environment () at /root/php5-5.5.9+dfsg/main/php_variables.c:625 #10 0x00007ffff3b7d34d in php_request_startup () at /root/php5-5.5.9+dfsg/main/main.c:1595 #11 0x00007ffff3d50fd7 in php_apache_request_ctor (r=0x7ffff7e8a0a0, ctx=0x7ffff7e864d0) at /root/php5-5.5.9+dfsg/sapi/apache2handler/sapi_apache2.c:502 #12 0x00007ffff3d515f8 in php_handler (r=0x7ffff7e8a0a0) at /root/php5-5.5.9+dfsg/sapi/apache2handler/sapi_apache2.c:618 #13 0x00005555555aa830 in ap_run_handler (r=0x7ffff7e8a0a0) at config.c:169 #14 0x00005555555aad79 in ap_invoke_handler (r=r@entry=0x7ffff7e8a0a0) at config.c:439 #15 0x00005555555c033a in ap_process_async_request (r=0x7ffff7e8a0a0) at http_request.c:317 #16 0x00005555555c0614 in ap_process_request (r=r@entry=0x7ffff7e8a0a0) at http_request.c:363 #17 0x00005555555bd0b2 in ap_process_http_sync_connection (c=0x7ffff7e8e290) at http_core.c:190 #18 ap_process_http_connection (c=0x7ffff7e8e290) at http_core.c:231 #19 0x00005555555b3e70 in ap_run_process_connection (c=0x7ffff7e8e290) at connection.c:41 #20 0x00005555555b4258 in ap_process_connection (c=c@entry=0x7ffff7e8e290, csd=<optimized out>) at connection.c:202 #21 0x00007ffff468a767 in child_main (child_num_arg=child_num_arg@entry=0) at prefork.c:704 #22 0x00007ffff468a96c in make_child (s=0x7ffff7fc1de0, slot=slot@entry=0) at prefork.c:746 #23 0x00007ffff468b6b1 in prefork_run (_pconf=<optimized out>, plog=0x7ffff7fbd028, s=0x7ffff7fc1de0) at prefork.c:956 #24 0x00005555555916de in ap_run_mpm (pconf=0x7ffff7ff0028, plog=0x7ffff7fbd028, s=0x7ffff7fc1de0) at mpm_common.c:96 #25 0x000055555558ae76 in main (argc=2, argv=0x7fffffffe658) at main.c:777 ------------------------------------------------------------------------ -- Edit this bug report at https://bugs.php.net/bug.php?id=69322&edit=1