The problem is that the code is doing `php_output_handler_free` in a loop on the output stack,
but prior to freeing the pointer on the stack in `php_output_handler_free` it calls
`php_output_handler_dtor` which can run user code that reallocates the stack,
resulting in a dangling pointer freed by php_output_handler_free.
Furthermore, OG(active) is set when creating a new output handler, but
the loop is supposed to clean up all handlers, so OG(active) must be
reset as well.
Closes GH-20356.
Since the ini message handlers already check for basedir, we need to
drop the basedir check from ini_set. Then we also fix the exceptional
case for the empty string: it should bypass the basedir check.
Furthermore, there was a regression introduced with the error_log
"syslog" check in ddfe269a (inverted check), so we fix that as well.
Closes GH-19487
The "else branch" of `next_line` can reset the `buf_begin` field to
NULL, causing the next invocation to pass NULL to `memchr` with a 0
length. When UBSAN is enabled this causes an UBSAN abort. Real world
impact is likely none because of the 0 length.
To fix this, don't set the pointer to NULL, which means that the
`memchr` will return NULL and since
`self->bytes_in_buffer < self->bufsize` we return NULL and request more
data through `fill_buffer`. That function will reset `buf_begin` and
`bytes_in_buffer` so that the next invocation works fine.
I chose this solution so we have an invariant that `buf_begin` is never
NULL, which makes reasoning easier. An alternative solution is keeping
the NULLing of `buf_begin` and add an extra check at the top of
`next_line`, but I didn't like special casing this.
Closes GH-17000.
When the superglobals are eagerly initialized, but "S" is not contained
in `variables_order`, `TRACK_VARS_SERVER` is created as empty array
with refcount > 1. Since this hash table may later be modified, a flag
is set which allows such COW violations for assertions. However, when
`register_argc_argv` is on, the so far uninitialized hash table is
updated with `argv`, what causes the hash table to be initialized, what
drops the allow-COW-violations flag. The following update with `argc`
then triggers a refcount violation assertion.
Since we consider `HT_ALLOW_COW_VIOLATION` a hack, we do not want to
keep the flag during hash table initialization, so we initialize the
hash table right away after creation for this code path.
Closes GH-15930.
multipart/form-data boundaries larger than the read buffer result in erroneous
parsing, which violates data integrity.
Limit boundary size, as allowed by RFC 1521:
Encapsulation boundaries [...] must be no longer than 70 characters, not
counting the two leading hyphens.
We correctly parse payloads with boundaries of length up to
FILLUNIT-strlen("\r\n--") bytes, so allow this for BC.
This merges all usages of emitting an offset TypeError into a new ZEND_API function
zend_illegal_container_offset(const zend_string* container, const zval *offset, int type);
Where the container should represent the type on which the access is attempted (e.g. string, array)
The offset zval that is used, where the error message will display its type
The type of access, which should be a BP_VAR_* constant, to get special message for isset/empty/unset
Multiple tests had to be changed to escape the arguments in shell
commands. Some tests are skipped because they behave differently with
spaces in the path versus without. One notable example of this is the
hashbang test which does not work because spaces in hashbangs paths are
not supported in Linux.
Co-authored-by: Michael Voříšek <mvorisek@mvorisek.cz>
Use a shared non-terminal for all class modifiers. This avoids conflicts when
adding modifiers that are only valid for certain targets. This change is
necessary for asymmetric visibility but might be useful for other future
additions.
Closes GH-9926
Directly referring to a constant of an undefined throws an exception;
there is not much point in `constant()` raising a fatal error in this
case.
Closes GH-9907.
When bug 77574[1] has been fixed, the fix only catered to variables
retrieved via `getenv()` with a `$varname` passed, but neither to
`getenv()` without arguments nor to the general import of environment
variables into `$_ENV` and `$_SERVER`. We catch up on this by using
`GetEnvironmentStringsW()` in `_php_import_environment_variables()` and
converting the encoding to whatever had been chosen by the user.
[1] <https://bugs.php.net/bug.php?id=75574>
Closes GH-7928.
