- Replace bailout on OOM with UnwindExit
- Properly reset various globals that may be accessed during startup
Fix GHSA-w8hw-w9fx-j79w (CVE-2026-109618)
Fix GHSA-6wmf-4rv5-p3rp (CVE-2026-109619)
Co-authored-by: Ilija Tovilo <ilija.tovilo@me.com>
Co-authored-by: Jakub Zelenka <bukka@php.net>
Co-authored-by: Nora Dossche <7771979+ndossche@users.noreply.github.com>
Co-authored-by: Nicolas Grekas <nicolas.grekas@gmail.com>
The current signature is effectively useless every call uses the _ex variant to be able to grab the FCC and usually the error message.
Something the current signature does not provide, and instead offers parameters that most call sites don't care about.
Closes GH-23996
Splitting the behavioural change of #23052 out into this and come up with something that is hopefully more sensible and consistent between fast and slow ZPP and the object or class_name Fast ZPP specifier.
These variants take the function as parameter instead of infering it from the
call stack. This is useful in ZEND_TYPE_ASSERT, and will be used in PFA impl.
The reason fake closures didn't compare as equal was that two different objects could represent the same fake closure.
Therefore, we need to do a more detailed comparison when one or both operands are closures rather than just comparing pointers.
A good follow-up would be to draft an RFC to fix the semantics of `==` with two different instances of the same fake closure.
These changes are based on a previous PR by @ndossche to reduce codebloat: https://github.com/php/php-src/pull/18436
For zend_parse_arg_str_weak() we can return a `zend_string*` directly, as errors can be indicated by a NULL pointer return.
For zend_parse_arg_double_weak() we can return a `double` directly, as we can represent ZPP errors via `NAN` as booleans and integers never coerce to NAN. One might think that the string `'NAN'` can be coerced to double `NAN`, however PHP doesn't allow this coercion. And an explicit cast to double via `(float)` of such a string results in 0.
For zend_parse_arg_bool_weak() we instead create a new enum zpp_parse_bool_status that represents a tri-state which we return. Allowing us to return the boolean value via the return type instead of using an out pointer.
Functions that use zend_forbid_dynamic_call() must be flagged with
ZEND_ACC2_FORBID_DYN_CALLS. In stubs, this is done by using
@forbid-dynamic-calls.
To ensure consistency, we assert that the flag exists in
zend_forbid_dynamic_call(), and we assert that flagged functions thrown after a
dynamic call.
Closes GH-21818
Change zend_function_entry.flags to a uint64_t to that both ZEND_ACC_ and
ZEND_ACC2_ flags can be represented.
Introduce ZEND_FENTRY_FLAGS(flags, flags2) to pass ZEND_ACC2_ flags to
ZEND_RAW_FENTRY(), ZEND_FENTRY().
Source-level backwards compatibility is maintained, as passing raw ZEND_ACC_
flags to ZEND_RAW_FENTRY(), ZEND_FENTRY() still works.
Update gen_stubs.php to generate C enums from internal enums, when the stub is annotated with @generate-c-enums. Enum values can be compared to the result of zend_enum_fetch_case_id(zend_object*).
The generated enums are added to separate files named {$extensionName}_decl.h, so that it's possible to include these from anywhere. _arginfo.h files would generate warnings if we tried to include them in a compilation unit that doesn't call the register_{$class} functions, for instance.
Introduce Z_PARAM_ENUM().
* Make ZEND_AST_CONST_ENUM_INIT a 4-children node
* Store enum case id in ZEND_AST_CONST_ENUM_INIT
* Store enum case id in instance
* Expose enum case_id internally
* Generate C enum for internal enums
* Introduce Z_PARAM_ENUM()
* Port extensions
The arg_info member of zend_function is now always a zend_arg_info*. Before,
it was a zend_internal_arg_info* on internal functions, unless the
ZEND_ACC_USER_ARG_INFO flag was set.
Closes GH-19022
* tree-wide: Replace `WRONG_PARAM_COUNT` by `ZEND_WRONG_PARAM_COUNT()`
This is a direct alias.
* tree-wide: Replace `ZEND_WRONG_PARAM_COUNT()` by its definition
This macro was hiding control flow (the return statement) and thus was
particularly unhygienic.
This is unused both within php-src and a SourceGraph search returned 0 results.
This is also confusing as it talks about symbol tables without actually using any of the corresponding update functions.
The initial motivation was to see if it is possible to make the `func` field of `_zend_execute_data` constant.
For various reasons, this is not possible, but the added `const` qualifiers during this exploration remain useful.
The name of this function is confusing, it doesn't make a zval callable just normalizes strings to an array pair if the string references a static method.
In general, to store a userland function it is encouraged to store the resolved FCC rather than the zval.
Moreover, a sourcegraph search shows no usage of this API in external open source code.
* tree-wide: Replace `CHECK_NULL_PATH()` by `zend_char_has_nul_byte()`
The former is a direct alias of the latter with a more explicit name and the
former is explicitly documented as a “compatibility” alias.
* tree-wide: Replace `CHECK_ZVAL_NULL_PATH()` by its definition
The former is explicitly documented as a “compatibility” alias.
* zend_API: Remove `CHECK*NULL_PATH`
The `CHECK_ZVAL_NULL_PATH()` macro is unsafe, because it implicitly assumes
that the given `zval*` is `IS_STRING`.
Based on a GitHub search there does not seem to be any user outside of PHP, all
hits were just forks / copies of php-src.
RFC: https://wiki.php.net/rfc/deprecations_php_8_5#remove_disable_classes_ini_setting
This took longer to merge than expected but the initial motivation from 2 years ago still applied:
As described in the email to the PHP internals list [1] this feature is fundamentally broken and pointless.
Only internal classes can be disable which brings the following observation. On a minimal build of PHP, with only the mandatory extensions enabled, there are 148 classes/interfaces/traits defined. [2]
Other than the SPL ones (and even then), disabling any of these classes will cause issues within the engine.
Moreover, the SPL ones are not a security concern.
Therefore, any other class that can be disabled must come from an extension that can be disabled altogether. And "disabling" a class from an extension without disabling said extension will render it useless anyway.
If a hosting provided is concerned about an extension, then it should not enable it in the first place. Not break it ad hoc.
Considering the above, I cannot see how this functionality was ever useful.
This is in stark contrast to the disable_functions INI setting, which can be used to selectively remove functionality of an extension without breaking it overall.
What makes this setting particularly broken is that it does not unregister the class, it only overwrites the create CE handler to emit a warning and purge the properties and function hashtables. This leads to various use after free, segfaults, and broken expectations for the engine and extensions which define said classes. On top of that, it is possible to actually instantiate such a class (and even classes which actually disallow this like ext/imap) in userland, and pass it to function that are typed against said class without raising a TypeError. However, when trying to do anything with said object stuff is going to explode in countless ways.
[1] https://news-web.php.net/php.internals/120896
[2] https://gist.github.com/Girgias/63d55ba1e50b580412b004046daed02b
Ilija Tovilo