Nikita Popov [Tue, 4 Feb 2020 13:19:07 +0000 (14:19 +0100)]
Fixed bug #78598
When performing an RW modification of an array offset, the undefined
offset warning may call an error handler / OB callback, which may
destroy the array we're supposed to change. Detect this by temporarily
incrementing the reference count. If we find that the array has been
modified/destroyed in the meantime, we do nothing -- the execution
model here would be that the modification has happened on the destroyed
version of the array.
Some code paths were checking this manually, but we can turn this
into a general assertion to avoid surprises (functions returning
failure without throwing).
I haven't tracked down in detail where the interaction with
increment_function comes from, but the root problem here is failure
to handle the illegal offset type exception.
In the interest of avoiding side-effects during dumping, I'm
replacing the value with a <constant ast> string instead of
performing an update constant operation.
The only case here that might be *somewhat* sensible is the userdata
argument of array_walk(), which could be used to keep persistent state
between callback invokations -- with the WTF moment that the final
result after the walk finishes will be unchanged. Nowdays, this is
much better achieved using a closure with a use-by-reference.
This causes some tests to fail. Those tests are specifically about
the callback not being able to modify the data though, so this is
clearly not supposed to be a supported use-case.
As part of my work on typed class constants, I wanted to make a
separate pull request for unrelated changes.
These include:
* Moving from ast->child[0]->attr to ast->attr
* Making zend_ast_export_ex() export class constants' visibility
* Extracting an additional zend_compile_class_const_group() function
We modify _basic1.phpt so it runs on Windows as well. The other test
cases hit the issue that `readlink()` fails normally for regular files,
but succeeds on Windows[1]. Therefore, we split these tests, but still
fix the skip reasons.
Most of these have been skipped on Windows for no good reason (`lstat`
is available there as of PHP 4). Several others would only fail,
because the `blksize` and `blocks` elements are always `-1` on Windows,
which can easily be fixed by using `%i` format specifiers instead of
`%d`.
Nikita Popov [Tue, 30 Jun 2020 15:28:47 +0000 (17:28 +0200)]
Remove bogus generator iterator dtor
Fixes a use-after-free encountered in Symfony's SecurityBundle.
I don't have a reproducer for this, and believe the issue can only
occur if we leak an iterator (the leak is a separate issue).
We should not free the generator iterator here, because we do not
own it. The code that fetched the iterator is responsible for
releasing it. In the rare case where we do hit this code-path,
we cause a use-after-free.
Nikita Popov [Tue, 30 Jun 2020 12:40:15 +0000 (14:40 +0200)]
Remove unnecessary ieeefp.h include
This was needed when php_config.h also declare compatibility
shims for isinf() and friends. These are no longer present in
master, so drop this include.
Eddie Kohler [Mon, 8 Jun 2020 12:29:42 +0000 (08:29 -0400)]
Make HashContexts serializable.
* Modify php_hash_ops to contain the algorithm name and
serialize and unserialize methods.
* Implement __serialize and __unserialize magic methods on
HashContext.
Note that serialized HashContexts are not necessarily portable
between PHP versions or from architecture to architecture.
(Most are, though Keccak and slow SHA3s are not.)
An exception is thrown when an unsupported serialization is
attempted.
Because of security concerns, HASH_HMAC contexts are not
currently serializable; attempting to serialize one throws
an exception.
Serialization exposes the state of HashContext memory, so ensure
that memory is zeroed before use by allocating it with a new
php_hash_alloc_context function. Performance impact is
negligible.
Some hash internal states have logical pointers into a buffer,
or sponge, that absorbs input provided in bytes rather than
chunks. The unserialize functions for these hash functions
must validate that the logical pointers are all within bounds,
lest future hash operations cause out-of-bounds memory accesses.
* Adler32, CRC32, FNV, joaat: simple state, no buffer positions
* Gost, MD2, SHA3, Snefru, Tiger, Whirlpool: buffer positions
must be validated
* MD4, MD5, SHA1, SHA2, haval, ripemd: buffer positions encoded
bitwise, forced to within bounds on use; no need to validate
projects / php / log