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
This is a quick fix for the problem.
It'll work while all the JIT-ed functions have the same "fixed stack frame".
Unwinder uses hard-coded unwind data for this "fixed stack frame".
* Preallocate space for Win64 shadow args
* typo
* Setup unwinder for JIT functions
* Revert "Dynamically xfail test case which fails on CI"
This reverts commit 7cc327fd5a.
* Revert "Dynamically xfail test case which fails on CI"
This reverts commit bdde797159.
* Revert "Dynamically xfail test cases which fail on CI (GH-15710)"
This reverts commit 6d5962074f.
* Remove XFAIL sections
* Add hard-coded SEH unwind data for EXITCALL
* Fix unwind data
* Fix Windows multi-process support
* Typo
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.
When an `PHP_OUTPUT_HANDLER_FAILURE` occurs, the output handler becomes
disabled (i.e. the `PHP_OUTPUT_HANDLER_DISABLED` flag is set). However,
there is no guard for disabled handlers in `php_output_handler_op()`
what may cause serious issues (as reported, UB due to passing `NULL` as
the 2nd argument of `memcpy`, because the handler's buffer has already
been `NULL`ed). Therefore, we add a respective guard for disabled
handlers, and return `PHP_OUTPUT_HANDLER_FAILURE` right away.
Closes GH-15183.
I added the function/method name to some compile-time deprecation messages which are related to parameters/return values. Consistently with the other similar error messages, I included the function/method name at the start of the message.
