|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #54350 Memory corruption with user_filter
Submitted: 2011-03-22 14:15 UTC Modified: 2021-01-08 16:36 UTC
Avg. Score:4.3 ± 0.9
Reproduced:1 of 2 (50.0%)
Same Version:1 (100.0%)
Same OS:1 (100.0%)
From: decoder-php at own-hero dot net Assigned:
Status: Closed Package: Reproducible crash
PHP Version: 5.3.6 OS: Linux x86-64
Private report: No CVE-ID: None
 [2011-03-22 14:15 UTC] decoder-php at own-hero dot net
The attached code shows a serious memory corruption (either crash or abort by glibc). I think I reported a similar testcase before (using filter) but the crash/corruption seemed different and I think it was not user_filter related, so it's not clear if this is a duplicate or not.

Test script:
class user_filter extends php_user_filter {
        function filter($in, $out, &$consumed, $closing) {
                while($bucket = stream_bucket_make_writeable($in)) {
$fd = fopen('php://memory','w');
$filter = stream_filter_append($fd, 'user_filter');
fwrite($fd, "foo");

Actual result:
When run on command line, terminated by glibc:

*** glibc detected *** /home/decoder/LangFuzz/php-trunk/sapi/cli/php: munmap_chunk(): invalid pointer: 0x00007fe4b1c7b420 ***

(+ backtraces)

When run in valgrind, the following happens (original testcase also segfaults here):

==10490== Invalid free() / delete / delete[]
==10490==    at 0x4C270BD: free (vg_replace_malloc.c:366)
==10490==    by 0x7C1211: zend_hash_del_key_or_index (zend_hash.c:521)
==10490==    by 0x7E1511: zend_std_unset_property (zend_object_handlers.c:768)
==10490==    by 0x700D8A: userfilter_filter (user_filters.c:262)
==10490==    by 0x742495: _php_stream_write_filtered (streams.c:1072)
==10490==    by 0x742630: _php_stream_write (streams.c:1138)
==10490==    by 0x69F820: zif_fwrite (file.c:1225)
==10490==    by 0x7ED653: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:638)
==10490==    by 0x7F37D2: ZEND_DO_FCALL_SPEC_CONST_HANDLER (zend_vm_execute.h:1935)
==10490==    by 0x7EC127: execute (zend_vm_execute.h:410)
==10490==    by 0x7B0348: zend_execute_scripts (zend.c:1212)
==10490==    by 0x726A6B: php_execute_script (main.c:2344)
==10490==  Address 0x6af28e8 is 256,808 bytes inside a block of size 262,144 alloc'd
==10490==    at 0x4C274A8: malloc (vg_replace_malloc.c:236)
==10490==    by 0x778CBA: zend_mm_mem_malloc_alloc (zend_alloc.c:287)
==10490==    by 0x77BB55: _zend_mm_alloc_int (zend_alloc.c:1971)
==10490==    by 0x779B92: zend_mm_startup_ex (zend_alloc.c:1122)
==10490==    by 0x779FBA: zend_mm_startup (zend_alloc.c:1217)
==10490==    by 0x77DB2E: alloc_globals_ctor (zend_alloc.c:2640)
==10490==    by 0x77DB45: start_memory_manager (zend_alloc.c:2656)
==10490==    by 0x7AEF4A: zend_startup (zend.c:642)
==10490==    by 0x725D5A: php_module_startup (main.c:1896)
==10490==    by 0x8EAD7B: php_cli_startup (php_cli.c:414)
==10490==    by 0x8EBB8A: main (php_cli.c:790)


in_free-hack (last revision 2014-04-04 08:59 UTC by mike dot php dot net at gmail dot com)

Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2011-03-31 12:30 UTC]
-Assigned To: +Assigned To: cataphract
 [2011-04-02 03:04 UTC]
Unfortunately this bug is just the tip of the iceberg. Resource management in the user filters has several problem. The oncreate and onclose methods also have problems and stack overflows can be caused by stream_filter_remove.

It's also possible that unsetting special properties such as .filter and .stream can cause problems.

I also don't see how these problems can be reliably fixed without modifying structures so this is going to be tough for PHP 5.3.
 [2011-12-27 09:58 UTC]
Thank you for taking the time to report a problem with PHP.
Unfortunately you are not using a current version of PHP -- 
the problem might already be fixed. Please download a new
PHP version from

If you are able to reproduce the bug with one of the latest
versions of PHP, please change the PHP version on this bug report
to the version you tested and change the status back to "Open".
Again, thank you for your continued support of PHP.

 [2011-12-27 09:58 UTC]
-Status: Assigned +Status: Bogus
 [2011-12-27 09:59 UTC]
Oops, wrong bug, sorry.
 [2011-12-27 09:59 UTC]
-Status: Bogus +Status: Open
 [2012-07-14 16:46 UTC]
-Type: Security +Type: Bug
 [2013-06-05 12:00 UTC] arjen at react dot com
Also broken in 5.4.15:
 [2017-10-24 07:59 UTC]
-Status: Assigned +Status: Open -Assigned To: cataphract +Assigned To:
 [2021-01-08 16:36 UTC]
-Status: Open +Status: Verified
 [2021-01-08 16:36 UTC]
A respective comment in the sources[1] clarifies:

| filter resources are cleaned up by the stream destructor,
| keeping a reference to the stream resource here would prevent
| it from being destroyed properly

So we need to convert stream resources to objects, where we can
introduce a cycle, which will eventually be resolved by the
garbage collector.

[1] <>
 [2021-10-06 18:49 UTC] bodik at cesnet dot cz
FYI likely a public PoC for the bug is here
 [2021-10-07 09:47 UTC]
Automatic comment on behalf of nikic
Log: Fixed bug #54350
 [2021-10-07 09:47 UTC]
-Status: Verified +Status: Closed
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Fri Jul 19 10:01:29 2024 UTC