Ouch, Z_TRY_ADDREF_P() uses pz twice... Also make sure we actually reserve
enough Buckets for all dynamic properties.
Fixes OSS-Fuzz #382922236
Closes GH-17085
Based on the discussion in GH-16286, drop the intl build from macOS + PHP 8.1,
since we cannot build with supported intl versions without too many changes.
Closes GH-17092
See GH-16286
phpize builds on Windows ignore the paths of extension sources, and
build all object files in the same folder. This can't work if there
are multiple source files with the same base name stored in separate
folders and registered as such (e.g. cls/worker.c and src/worker.c).
While extension authors can work around by avoiding duplicate base
names, they may not even be aware of the problem because on POSIX
systems, the object files are usually placed right besides the sources.
Thus we take the relative path (from `configure_module_dirname`) of the
source files into account even for phpize builds. Since this may break
some extension builds (especially those which use Makefile fragments),
we do not apply this fix to stable branches.
Closes GH-17016.
It seems reasonable to have an ASan job on Windows, especially to be
able to check Windows specific code. Since the tests may take about
70 minutes, it doesn't make sense to add these for pushes, but for a
nightly job that should be okay.
Closes GH-17087.
The `jit_prof_threshold` is a float, supposed to be in range [0, 1],
and usually very small (the default is 0.005). Reporting it as int
is meaningless.
Closes GH-17077.
Besides that is generally good practice to avoid macro redefinitions
(and symbol redeclarations), and we're doing this on POSIX platforms
anyway, there is a particular issue regarding phpize builds, where
config.w32.h actually includes config.pickle.h. The latter overrides
some macro definitions (e.g. `PHP_BUILD_SYSTEM`) to define the proper
values, but if config.w32.h is included multiple times, different macro
definitions eventually raise C4005 compiler warnings[1], which break
builds with `/WX /W1` enabled.
[1] <https://learn.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-level-1-c4005>
As is, whenever `proc_open()` needs to invoke the shell, cmd.exe is
looked up in the usual executable search path. That implies that any
cmd.exe which is placed in the current working directory (which is not
necessarily what is reported by `getcwd()` for ZTS builds), will be
used. This is a known attack vector, and Microsoft recommends to
always use the fully qualified path to cmd.exe.
To prevent any cmd.exe in the current working directory to be used, but
to still allow users to use a drop in replacement for cmd.exe, we
search only the `PATH` for cmd.exe (and pass the fully qualified path
to `CreateProcessW`), instead of relying on automatic executable search
by passing the base name only.
To be able to easily test this, we provide a minimalist C file which
will be build as test_helper, and used by the new test case.
[1] <https://msrc.microsoft.com/blog/2014/04/ms14-019-fixing-a-binary-hijacking-via-cmd-or-bat-file/>
Closes GH-17043.
These tests execute php.exe without passing the PATH, what might be a
more general issues, but at least with ASan enabled, the required DLLs
could usually not be found, resulting in the tests stalling.
Closes GH-17079.
Pipes are blocking on Windows, but `php_select()` always returns them
as ready for read/write. This renders the `stream_select()` timeout
useless, what can cause a following read to block for a very long time.
While there is no general fix (and least not within reach for a stable
version), we can at least cater to the important case of read pipes by
peeking the pipe to check whether data is available. If there is none,
we do not add the handle to the read set.
We need to fix a couple of tests cases:
* bug60692.phpt and bug64770.phpt assume that at least the stdin and
stdout pipes are always selected as readable, and that the select
call will not change their order. We're being more defensive now.
* the potentials warnings of bug49936_win32.phpt need to be suppressed,
like it has been done earlier for the POSIX variant of this test
case[1]. Possibly this test case should be dropped altogether[2].
[1] <c884d3782c>
[2] <2c6b85f6fe>
Closes GH-16917.
While it is already possible to enable ASan for MSVC (assuming Visual
Studio 2019 16.10 or later) by passing `/fsanitizer=address` in the
`CFLAGS`, it is only usable if `ZEND_DEBUG` is also enabled; otherwise
there are `STATUS_BACK_STACK` errors all the time.
Since it makes some sense to combine ASan instrumentation with debug
assertions enabled anyway (typical for fuzzing), we support the
configure option `--enable-sanitizer`, which is already supported for
Clang builds, also for MSVC builds. Note that MSVC supports only ASan
for now; contrary to Clang which additionally supports UBSan on Windows.
Since ASan reports can be pretty useless without debug symbol
information, we require such builds to also produce PDBs (i.e.
`--enable-debug-pack`), but forbid actual debug builds (for performance
reasons, and because the way it is implemented it would not make sense;
that was already an issue with Clang builds with sanitizers enabled).
Closes GH-16999.
Besides that just checking for icuuc.lib does not necessarily imply
that the other libraries are available, doing it this way will not copy
the PDBs to the build folder, so these are not available in the debug
packages. Furthermore, `CHECK_LIB` already adds the library to the
flags, so there is no need to do this manually.
Closes GH-17010.
The only difference between `DateTime::__wakeup()` and
`DateTimeImmutable::__wakeup()` is which class name is included in the error
message if the initialization from the data fails. Factor out a helper method
that is given the class name, and use it for both methods.
This test reads an ini "file" from a string, and expects a warning
about locking. But if inifile support is disabled, then you'll get
Warning: dba_open(): Handler "inifile" is not available in
/path/to/ext/dba/tests/gh16390.php on line 3
instead. We skip the test if inifile support is disabled.
Closes GH-17011.
There are edge cases where computations can cause an integer overflow,
which is undefined behaviour. Lately, some fuzzers seem to be hitting
these quite frequently. While this behaviour is undefined, it doesn't
actually matter in practice, the worst effect is having a wrong
computation result, but no sane person would do computations on e.g. the
year pow(2,63).
Still, undefined behaviour is bad.
Make the wrapping behaviour defined by using -fwrapv when possible.
The scope of this is limited to timelib and doesn't affect php_date.c.
The reason for this is that this may in theory prevent some
optimizations and it also seems bad to affect code that lives so close
to the PHP-native edge.
I tested all issues.
This fixes all but one issues, the remaining issue is in php_date.c.
Fixes GH-13881.
Fixes GH-14075.
Fixes GH-15150.
Fixes GH-16034.
Fixes GH-16035.
Fixes GH-16048.
Fixes GH-16050.
Fixes GH-16051.
Fixes GH-16052.
Fixes GH-16775.
Fixes GH-16864.
Fixes GH-16865.
Fixes GH-16975.
Fixes GH-17025.
Fixes GH-17059.
Closes GH-17060.
