The error handling is incomplete on argument cleanup.
1. The fci is not cleared which means that zend_free_trampoline() is
never called.
2. The cleaning for extra named arguments was missing, resulting in
memory leak.
Closes GH-17219.
When observer is enabled, we normally add an extra temporary to all
functions, to store the previously observed frame. However, this is done in
zend_observer_post_startup() so it doesn't happen to dl'ed() functions.
One possible fix would be to move that from zend_observer_post_startup()
to zend_register_functions(), but this would be too early: Observer may
not be enabled when zend_register_functions() is called, and may still be
enabled later.
However, when zend_register_functions() is called at run-time (during dl()),
we know definitively whether observer is enabled.
Here I update zend_register_functions() to add a temporary to dl'ed()
functions when observer is enabled.
Fixes: GH-17211
Closes: GH-17220
op1 of ZEND_MATCH_ERROR, which refers to the match expression, is not freed by
MATCH_ERROR itself. Instead, it is freed by ZEND_HANDLE_EXCEPTION. For normal
control flow, a FREE is placed at the end of the match expression.
Since FREE may appear after MATCH_ERROR in the opcode sequence, we need to
correctly handle op1 of MATCH_ERROR as alive.
Fixes GH-17106
Closes GH-17108
Only on Windows `IS_SLASH_P()` may read the previous byte, and so may
in unlikely cases read one byte out of bounds. Since `IS_SLASH_P()` is
in a public header (albeit not likely to be used by external extensions
or SAPIs), we introduce `IS_SLASH_P_EX()` which accepts a second
argument to prevent that OOB read.
It should be noted that the PHP userland function `dirname()` is not
affected by this issue, since it does not call `zend_dirname()` on
Windows.
Closes GH-16995.
We should compare the block memory, not the block metadata (See
zend_mm_add_huge_block).
This caused random test failure for ext/ffi/tests/gh14626.phpt when the
malloc() performed by the FFI code lies close to the block metadata, and
the size of the block is large enough.
This was reported by https://github.com/php/php-src/issues/16902#issuecomment-2498310452
Closes GH-16938.
zend_save_lexical_state() can be nested multiple times, for example for
the parser initialization and then in the heredoc lexing. The input
should not be freed if we restore to the same filtered string.
Closes GH-16716.
zend_is_callable_ex() can unfortunately emit a deprecation, and then
a user error handler can throw an exception. This causes an assert
failure at ZEND_VM_NEXT_OPCODE(). We fix this by checking if there's an
exception after zend_is_callable_ex().
Closes GH-16803.
Reproducer: https://github.com/php/php-src/issues/16727#issuecomment-2466256317
The root cause is a data race between two different threads:
1) We allocate a lower cased name for an anonymous class here:
f97353f228/Zend/zend_compile.c (L8109)
2) This gets looked up as an interned string here:
f97353f228/Zend/zend_compile.c (L8112)
Assuming that there are uppercase symbols in the string and therefore
`lcname != name` and that `lcname` is not yet in the interned string table,
the pointer value of `lcname` won't change.
3) Here we add the string into the interned string table:
f97353f228/Zend/zend_compile.c (L8223)
However, in the meantime another thread could've added the string into the interned string table.
This means that the following code will run, indirectly called via the `LITERAL_STR` macro,
freeing `lcname`: 62e53e6f49/ext/opcache/ZendAccelerator.c (L572-L575)
4) In the reproducer we then access the freed `lcname` string here:
f97353f228/Zend/zend_compile.c (L8229)
This is solved in my patch by retrieving the interned string pointer
and putting it in `lcname`.
Closes GH-16748.
These have been introduced a while ago[1], but their initialization has
been overlooked. Since we cannot rely on TLS variables to be zeroed,
we catch up on this.
[1] <e3ef7bbbb8>
Co-authored-by: Ilija Tovilo <ilija.tovilo@me.com>
Closes GH-16658.
The inline assembly uses labels with the prefix `.L`. On Linux systems
this is the local label prefix. It appears that macOS uses `L` as a
local prefix, which means that the prefix used in the inline assembly is not
local for macOS systems [1].
When combined with inlining, this causes the compiler to get confused
and merge a part of the inline assembly between different functions,
causing control flow to jump from one function to another function.
This is avoided on PHP 8.2 and up by the fact that it
uses `zend_never_inline NOIPA`, but nothing guarantees that compiler
changes won't affect this as well.
To solve this issue, we instead use local labels. These will make the
compiler pick the correct prefix, preventing the issue.
Additionally, while here, we also change the computation of `delta`.
It is undefined behaviour to compute the pointer difference between
two different objects. To circumvent this, we cast first to `uintptr_t`.
This change is cleanly backportable to 8.1 for vendors to pick up.
[1] https://github.com/php/php-src/issues/16168#issuecomment-2404792553
With the help of investigation and testing of @ryandesign.
Closes GH-16348.
