Trying to allocate a `zend_string` with a length only slighty smaller
than `SIZE_MAX` causes an integer overflow; we make sure that this
doesn't happen by catering to the maximal overhead of a `zend_string`.
Closes GH-7597.
When more than INT_MAX resource are created, throw a fatal error,
rather than reusing already allocated IDs, which will result in
assertion failures or crashes down the line.
This doesn't fix the fundamental problem, but makes the failure
more graceful with an obvious cause.
Inspired by https://bugs.php.net/bug.php?id=81399.
Closes GH-7428.
In this case we should use the original internal handler. Otherwise
the trampoline will attempt to free the closure, but the function
being used is not actually part of a closure anymore.
We must avoid integer overflows in memory allocations, so we introduce
an additional check in the VM, and bail out in the rare case of an
overflow.
Closes GH-7381.
We must avoid integer overflows in memory allocations, so we introduce
an additional check in the VM, and bail out in the rare case of an
overflow. Since the recent fix for bug #74960 still doesn't catch all
possible overflows, we fix that right away.
While parent:: should inherit the called scope, it should only do
so if it is compatible. If there is no called scope, or it is not
a subtype of the scope, we should fall back to the scope.
Trying to allocate a `zend_string` with a length only slighty smaller
than `SIZE_MAX` causes an integer overflow, so callers may need to
check that explicitly. To make that easy in a portable way, we
introduce `ZSTR_MAX_LEN`.
Closes GH-7294.
For a particular assignment, a non-coerced constant assignment
value will remain valid. However, opcache merges cache slots for
all identical property references, which means that this
optimization also disables property type checks for all other
operands on the property that occur in the same functions.
This could be addressed by blocking cache slot merging in opcache,
but I prefer dropping it entirely instead. It does not seem
important enough to warrant doing that.
The analysis in the bug report wasn't correct (at least not in
this case -- there may still be a more general problem here),
the issue was that write_property returned the original variable_ptr
rather than the zend_assign_to_variable() return value, which will
DEREF the variable before overwriting it.
In this case we ended up creating an ASSIGN_OBJ_REF with VAR
result operand, which was not freed.
Fix this by implementing assign_ref_znode the same was as
assign_znode, i.e. performing an assignment with result and
then freeing the result, which will result mark the result as
UNUSED. This is more robust than the special handling for
result == NULL that was used before.
This fixes one of the issues reported in bug #81190.
When the memory limit is restored during shutdown, we may still
be using a lot of memory. Ignore the failure at that point and
set it again after the MM is shut down, at which point memory
usage should be at its lowest point.
When the memory limit is reduced using an `ini_set("memory_limit", ..)`
below the currently allocated memory, the out-of-memory check overflowed.
Instead of implementing additional checks during allocation,
`zend_set_memory_limit()` now validates the new memory limit. When
below the current memory usage the ini_set call will fail and throw
a warning.
This is part of GH-7040.
For concatenation, the in-place variant can be much more efficient,
because it will reallocate the string in-place. Special-case the
typed property compound assignment code for the case where we
concatenate to a string, in which case we know that the result
will also be a string, and we don't need the type check anyway.
If ZTS is enabled, this can cause cwd_globals_ctor() to be called
multiple times, each with a freshly allocated virtual_cwd_globals
instance. At shutdown time however, cwd_globals_dtor() will call
realpath_cache_clean(), which then possibly cleans up the same
realpath_cache instance more than once. Using AddressSanitzer, this
shows up as a heap use-after-free.
To avoid this, add a helper function to do the actual work on one
instance of a realpath_cache, and call it both from cwd_globals_dtor()
and realpath_cache_clean(). The former uses the virtual_cwd_globals
parameter passed in via the destructor, the latter uses the CWDG()
macro.
Firstly, we must not forget to set appropriate error codes for "manual"
checks in `virtual_file_ex()`.
Secondly, we must not call `php_error_docref2()` for warnings regarding
unary functions; thus, we introduce `php_win32_docref1_from_error()`.
Closes GH-6872.
The function name should be kept if Closure was created from the function which is marked as ZEND_ACC_CALL_VIA_TRAMPOLINE, because it is not a one-time thing and it may be called multiple times.
Closes GH-6867.
zend_find_array_dim_slow() may throw, make sure to handle this.
This backports the code we already use for this on PHP-8.0,
and also backports an exception check that makes this easier to
catch.
We need to first clean the symtable and then check whether a cache
slot is available for it. Otherwise, it may happen that a destructor
runs while cleaning the table and uses up all the remaining slots
in the cache.
This is particularly insidious because once we overflow the cache,
the first pointer we modify is symtable_cache_ptr, making it hard
to understand what happened after the fact.
Fixes oss-fuzz #30815.
Don't truncate the file length to unsigned int...
I have no idea whether that fully fixes the problem because the
process gets OOM killed before finishing, but at least the
immediate parse error is gone now.
Like Cygwin, this platform needs to use a real-time timer.
This was based on a patch by @kadler, but it didn't handle unsetting
the timer, so the timeout would continue to be active, triggering
`hard_timeout` unexpectedly. The patch is fixed to handle unsetting.
Closes GH-6503.
Our CPU detection code currently only checks whether hardware
support for AVX exists. However, we also need to check for operating
system support for XSAVE, as well as whether XCR0 has the SSE and
AVX bits set.
If this is not the case, unset the AVX and AVX2 bits in the cpuinfo
structure.
Hopefully this resolves our issues with CPU support detection.
Closes GH-6460.
For x ? y : z style structures, the live range starts at z, but
may also hold the value of y. Make sure that the refcounting check
takes this into account, by checking the type of a potential phi
user.
Failure to rebind such closures is not necessarily related to them
being created by `ReflectionFunctionAbstract::getClosure()`, so we fix
the error message.
Closes GH-6424.
We should use normal function renaming if the function is declared
during preloading itself, rather than afterwards.
This fixes a regression introduced by
68f80be9d1.
A recent bug fix regarding symlinks claimed:
> After resolving reparse points, the path still may be a reparse
> point; in that case we have to resolve that reparse point as well.
While that is basically correct, some reparse points may point to
inaccessible system folders (e.g. `IO_REPARSE_TAG_DEDUP` points to
"\System Volume Information"). Since we don't know details about
arbitrary reparse points, and are mainly interested in nested symlinks,
we take a step back, and only resolve `IO_REPARSE_TAG_SYMLINK` for now.
Close GH-6354.
If the RHS has INDIRECT elements, we do not those to be added to
the LHS verbatim. As we're using UPDATE_INDIRECT, we might even
create a nested INDIRECT that way.
This is a side-quest of oss-fuzz #26245.
