#48633 [NEW]: str_pad() with giant lenth value and no memory limit infinite-loops or crashes

From: gwynne@php.net Operating system: Darwin9 (MacOS X 10.5) PHP version: 5.3CVS-2009-06-22 (CVS) PHP Bug Type: Reproducible crash Bug description: str_pad() with giant lenth value and no memory limit infinite-loops or crashes Description: ------------ Calling str_pad($anything, PHP_INT_MAX) causes one of four symptoms: 1) If memory_limit is set below 2GB, a fatal error is thrown saying the memory limit is exhausted with an attempt to allocate 2GB. This appears to be the expected result. 2) If memory_limit is set above 2GB, or is unset, PHP (in or out of GDB) enters a massive CPU-eating swap-file-smashing loop. 3) If PHP is being run under valgrind, PHP exits quickly with a memory allocation failure because valgrind's malloc() replacement refuses the "nonsense" allocation request. 4) If PHP is being run under valgrind *and* run-tests.php, PHP crashes with a NULL pointer reference. This is caused by two problems in the str_pad code: 1) The value of num_pad_chars is not bounds-checked in ext/standard/string.c:4830 2) The return value of emalloc() is not checked for NULL on the same line. Reproduce code: --------------- 1) $ sapi/cli/php ext/standard/tests/string/str_pad_variation5.phpt 2) $ sapi/cli/php -dmemory_limit=1 ext/standard/tests/string/str_pad_variation5.phpt 3) $ valgrind sapi/cli/php -dmemory_limit=1 ext/standard/tests/string/str_pad_variation5.phpt 4) $ PHP_TEST_EXECUTABLE=pwd/sapi/cli/php sapi/cli/php run-tests.php -m ext/standard/tests/string/str_pad_variation5.phpt Expected result: ---------------- In all cases, str_pad() should recognize that its argument is ridiculous and return without trying to make the allocation. Actual result: -------------- 1) *** Testing str_pad() function: with large value for for 'pad_length' argument *** Fatal error: Allowed memory size of 134217728 bytes exhausted at ext/standard/string.c:4830 (tried to allocate 2147483648 bytes) in ext/standard/tests/strings/str_pad_variation5.phpt on line 25 2) PHP starts running at 100% CPU and eating huge amounts of swap space. 3) *** Testing str_pad() function: with large value for for 'pad_length' argument *** ==31081== Warning: silly arg (-2147221504) to malloc() Fatal error: Out of memory (allocated 524288) at ext/standard/string.c:4830 (tried to allocate 2147483648 bytes) in ext/standard/tests/strings/str_pad_variation5.phpt on line 25 4) ==31145== Warning: silly arg (-2147483648) to malloc() ==31145== Invalid write of size 1 ==31145== at 0x823B13: memcpy (mc_replace_strmem.c:482) ==31145== by 0x2B3F92: zif_str_pad (string.c:4855) ==31145== by 0x3E2D98: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:313) ==31145== by 0x3E9151: ZEND_DO_FCALL_SPEC_CONST_HANDLER (zend_vm_execute.h:1601) ==31145== by 0x3E1B59: execute (zend_vm_execute.h:104) ==31145== by 0x3AE947: zend_execute_scripts (zend.c:1188) ==31145== by 0x31E6CC: php_execute_script (main.c:2196) ==31145== by 0x499E5F: main (php_cli.c:1188) ==31145== Address 0x0 is not stack'd, malloc'd or (recently) free'd ==31145== ==31145== Process terminating with default action of signal 10 (SIGBUS) ==31145== Non-existent physical address at address 0x0 ==31145== at 0x823B13: memcpy (mc_replace_strmem.c:482) ==31145== by 0x2B3F92: zif_str_pad (string.c:4855) ==31145== by 0x3E2D98: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:313) ==31145== by 0x3E9151: ZEND_DO_FCALL_SPEC_CONST_HANDLER (zend_vm_execute.h:1601) ==31145== by 0x3E1B59: execute (zend_vm_execute.h:104) ==31145== by 0x3AE947: zend_execute_scripts (zend.c:1188) ==31145== by 0x31E6CC: php_execute_script (main.c:2196) ==31145== by 0x499E5F: main (php_cli.c:1188) -- Edit bug report at http://bugs.php.net/?id=48633&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=48633&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=48633&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=48633&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=48633&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=48633&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=48633&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=48633&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=48633&r=needscript Try newer version: http://bugs.php.net/fix.php?id=48633&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=48633&r=support Expected behavior: http://bugs.php.net/fix.php?id=48633&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=48633&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=48633&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=48633&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48633&r=php4 Daylight Savings: http://bugs.php.net/fix.php?id=48633&r=dst IIS Stability: http://bugs.php.net/fix.php?id=48633&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=48633&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=48633&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=48633&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=48633&r=mysqlcfg