Skip to content

Conversation

@cmb69
Copy link
Member

@cmb69 cmb69 commented Sep 7, 2016

The PHP core and extensions are written with the assumption that memory
allocation either succeeds, or the allocator bails out (i.e. the allocator
is infallible). Therefore the result of emalloc() and friends are not checked
for NULL values.

However, with USE_ZEND_ALLOC=0, malloc() and friends are used as allocators,
but these are fallible, i.e. they return NULL instead of bailing out if they
fail. This easily leads to invalid memory accesses in the following, such as
in https://bugs.php.net/73032. Some of these cases may constitute
exploitable vulnerabilities.

Therefore we make the infallible __zend_alloc() and friends the default for
USE_ZEND_ALLOC=0.

The PHP core and extensions are written with the assumption that memory
allocation either succeeds, or the allocator bails out (i.e. the allocator
is infallible). Therefore the result of emalloc() and friends are not checked
for NULL values.

However, with USE_ZEND_ALLOC=0, malloc() and friends are used as allocators,
but these are fallible, i.e. they return NULL instead of bailing out if they
fail. This easily leads to invalid memory accesses in the following, such as
in <https://bugs.php.net/73032>. Some of these cases may constitute
exploitable vulnerabilities.

Therefore we make the infallible __zend_alloc() and friends the default for
USE_ZEND_ALLOC=0.
@nikic
Copy link
Member

nikic commented Sep 7, 2016

Looks reasonable. The only downside is that we waste one stack frame in valgrind :)

@cmb69
Copy link
Member Author

cmb69 commented Sep 7, 2016

Note, that I consider the current behavior a serious bug, unless it would be documented that fallible memory managers must not be used for production environments. But even in this case, we probably can avoid a lot of (security) bug reports (such as https://bugs.php.net/73032) by simply using an infallible memory allocator.

Furthermore, the PHP manual should make it clear that custom memory managers are supposed to be also infallible.

@cmb69
Copy link
Member Author

cmb69 commented Sep 7, 2016

The only downside is that we waste one stack frame in valgrind :)

--num-callers to the rescue. :-)

@cmb69
Copy link
Member Author

cmb69 commented Sep 7, 2016

The failing Travis check is unrelated to this PR.

@KalleZ
Copy link
Member

KalleZ commented Sep 9, 2016

cc @dstogov

@dstogov
Copy link
Member

dstogov commented Sep 12, 2016

looks fine. BTW USE_ZEND_ALLOC=0 was introduced (and should be used) for debugging memory problems only.

@cmb69
Copy link
Member Author

cmb69 commented Sep 13, 2016

BTW USE_ZEND_ALLOC=0 was introduced (and should be used) for debugging memory problems only.

I'll adjust the documentation accordingly.

Nonetheless, I consider the current behavior to be a bug, and therefore have targetted the PR to PHP 5.6. If there are no objections, I'm going to merge in a week.

salathe pushed a commit to salathe/phpdoc-en that referenced this pull request Sep 13, 2016
LawnGnome pushed a commit to LawnGnome/phpdoc-en that referenced this pull request Sep 13, 2016
svn2github pushed a commit to svn2github/phpdoc_en that referenced this pull request Sep 13, 2016
@php-pulls php-pulls merged commit 5880428 into php:PHP-5.6 Sep 24, 2016
@cmb69 cmb69 deleted the infallible-malloc branch October 11, 2016 14:32
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants