Don't misinterpret DJI info maker note as DJI maker note.
The DJI and DJI info maker note both share the "DJI" make string.
This caused the current code to try to interpret the DJI info maker note
as a DJI maker note. However, the DJI info maker note requires custom
parsing. Therefore, the misinterpretation actually caused the current
code to believe that there was an unrecoverable error in the IFD for the
maker note by returning false in the maker note parser. This in turn
caused the inability to parse other EXIF metadata.
This patch adds the identification of the DJI info maker note so that it
cannot be misinterpreted. Since we don't implement custom parsing, it
achieves this by setting the tag list to a special marker value (in this
case the NULL pointer). When this marker value is detected, the function
will just skip parsing the maker note and return true. Therefore, the
other code will believe that the IFD is not corrupt.
This approach is similar to handing an unrecognised maker note type
(see the loop on top of exif_process_IFD_in_MAKERNOTE() which also
returns true and treats it as a string). The end result of this patch
is that the DJI info maker note is considered as unknown to the caller of
exif_process_IFD_in_MAKERNOTE(), and therefore that the other EXIF
metadata can be parsed successfully.
Also fix debug output typos in exif.
Closes GH-10470.
Discovered this pre-existing problem while testing GH-10682.
Note: this problem existed *before* that PR.
* Not all paths throw a hierarchy request error
* xmlFreeNode must be used instead of xmlFree for the fragment to also
free its children.
* Free up nodes that couldn't be added when xmlAddChild fails.
I unified the error handling code that's exactly the same with a goto to
prevent at least some of such problems in the future.
Closes GH-10981.
The ZVAL_ARR macro always set the zval type_info to IS_ARRAY_EX, even if the
hash table is immutable. Since in preg_replace_callback_array() we can return
the passed array directly, and that passed array can be immutable, we need to
reset the type_flags to keep the VM from performing ref-counting on the array.
Fixes GH-10968
Closes GH-10970
This was first pointed out in GH-10959.
The from_zval_... functions don't always write to the pointer, in particular
it is necessary to check for an error before using the value. Otherwise
we can access an uninitialized value and that's UB (and dangerous).
Note: this does *NOT* get rid of the compiler warning. Even though there
is error checking now, the compiler isn't smart enough to figure out
that the values can not be used uninitialized.
Closes GH-10966.
atoi()'s return value is actually undefined when an underflow or
overflow occurs. For example on 32-bit on my system the overflow test
which inputs "h2147483648" results in repetitions==2147483647 and on
64-bit this gives repetitions==-2147483648. The reason the test works on
32-bit is because there's a second undefined behaviour problem:
in case 'h' when repetitions==2147483647, we add 1 and divide by 2.
This is signed-wrap undefined behaviour and accidentally triggers the
overflow check like we wanted to.
Avoid all this trouble and use strtol with explicit error checking.
This also fixes a semantic bug where repetitions==INT_MAX would result
in the overflow check to trigger, even though there is no overflow.
Closes GH-10943.
The recent clang-16 throws errors for implicitly defined functions by
default. In many ./configure tests, an undefined function (which is
"implicitly defined" when you try to call it) is undefined because it
really does not exist. But in one case, utf8_to_mutf7() is undefined
because we forgot to include the header that defines it.
This commit updates the test for utf8_to_mutf7:
* We now include the header (c-client.h) that defines it.
* A "checking... yes/no" message was added to the test.
* The test was switched from PHP_IMAP_TEST_BUILD to AC_COMPILE_IFELSE.
This was the easiest way to avoid a return-type mismatch that runs
afoul of -Werror=implicit-int.
* CPPFLAGS is temporarily amended with the -I flag needed to find
c-client.h.
Fixes GH-10947.
Closes GH-10948
Signed-off-by: George Peter Banyard <girgias@php.net>
The alignment of sqldata is in most cases only the basic alignment,
so the code type-puns it to a larger type, it *can* crash due to the
misaligned access. This is only an issue for types > 4 bytes because
every sensible system requires an alignment of at least 4 bytes for
allocated data.
Even though this patch uses memcpy, the compiler is smart enough to
optimise it to something more efficient, especially on x86.
This is just the usual approach to solve these alignment problems.
Actually, unaligned memory access is undefined behaviour, so even on x86
platforms, where the bug doesn't cause a crash, this can be problematic.
Furthermore, even though the issue talks about a 64-bit kernel and
32-bit userspace, this doesn't necessarily need to be the case to
trigger this crash.
Test was Co-authored-by: rvk01
Closes GH-10920.
Signed multiply overflow is undefined behaviour.
If you run the CI tests with UBSAN enabled on a 32-bit platform, this is
quite easy to hit. On 64-bit it's more difficult to hit though, but not
impossible.
Closes GH-10942.
As shown on the CI runs on my fork (which runs with UBSAN),
the pointers can sometimes be unaligned when trying to write.
This is UB and on platforms like ARM this *can* result in a bus error.
Replace it with memcpy, which at least on x86 and powerpc
architectures does result in the same assembly code.
Closes GH-10940.
At least on 32-bit, the address computations overflow in running the
test on CI with UBSAN enabled. Fix it by reordering the arithmetic.
Since a part of the expression is already used in the code above the
computation, this should not negatively affect performance.
Closes GH-10936.
It's possible that curl was compiled without SSL, and/or without libz
support. In the case of the issue reporter it was without libz support.
This causes the test to fail because we expect a non-empty string.
Fix it by using %S instead of %s to allow empty strings.
Closes GH-10930.
Previously, mbstring used the same logic for encoding validation as for
encoding conversion.
However, there are cases where we want to use different logic for validation
and conversion. For example, if a string ends up with missing input
required by the encoding, or if a character is input that is invalid
as an encoding but can be converted, the conversion should succeed and
the validation should fail.
To achieve this, a function pointer mb_check_fn has been added to
struct mbfl_encoding to implement the logic used for validation.
Also, added implementation of validation logic for UTF-7, UTF7-IMAP,
ISO-2022-JP and JIS.
(The same change has already been made to PHP 8.2 and 8.3; see
6fc8d014df. This commit is backporting the change to PHP 8.1.)
The stream context inside `mysqlnd_vio::enable_ssl()` is leaking.
In particular: when `php_stream_context_set()` get called the refcount
of `context` is increased by 1, which means that `context` will now
have a refcount of 2. Later on we remove the context from the stream
by calling `php_stream_context_set(stream, NULL)` but that leaves our
`context` with a refcount of 1, and therefore it's never destroyed.
In my test case this yielded a leak of 1456 bytes per connection
(but could be more depending on your settings ofc).
Annoyingly, Valgrind doesn't find it because the context is still
in the `EG(regular_list)` and will thus be destroyed at the end of
the request. However, I still think this bug needs to be fixed because
as the users in the issue report already mentioned:
there can be long-running PHP scripts.
Fix it by decreasing the refcount to transfer the ownership.
Closes GH-10909.
The char arrays were too small for a long on 64-bit systems, which
resulted in cutting off the string at the end with a NUL byte. Use a
size of MAX_LENGTH_OF_LONG to fix this issue instead of a fixed size
of 11 chars.
Closes GH-10525.
get_browser() implements a lazy parse system for the browscap
INI configuration. There are two possible moments when a browscap
configuration can be loaded: during module startup or during request.
In case of module startup, the strings are persistent strings, while for
the request they are not.
The INI parser must therefore know whether to create persistent or
non-persistent strings. It does this by looking at
CG(ini_parser_unbuffered_errors). If that value is 1 it's persistent,
otherwise non-persistent. Note that this also controls how the errors
are reported: if it's 1 then the errors are sent to stderr, otherwise we
get E_WARNINGs.
Currently, a hardcoded value of 1 is always used for that CG value in
browscap_read_file(). This means we'll always create persistent strings
*and* we'll not report parse errors correctly as E_WARNINGs.
We fix both the crash and the lack of warnings by passing the value of
persistent instead of a hardcoded 1.
This is also in line with how other INI parsing code is called in
ext/standard: they also make sure that during request a value of 0 is
passed.
Closes GH-10883.
* Missing check: SQLAllocHandle() for the environment wasn't checked in
pdo_odbc_handle_factory(). Add a check similar to the other ones for
SQLAllocHandle().
* Inconsistent check: one of the SQLAllocHandle() calls wasn't checked
for SQL_SUCCESS_WITH_INFO. However, looking at the other uses and the
documentation we should probably check this as well.
Furthermore, since there was a mix of "SQLAllocHandle: reason" and
"SQLAllocHandle (reason)" in the error reporting, I made them
consistently use the first option as that seems to be the most used for
error reporting in this file.
Closes GH-10740.
Commit a21195650e fixed a leak by adding a TSRM destructor for the
JIT globals in ZTS mode. In case the main thread shuts down the TSRM, it
will call all the destructors. The JIT globals destructor will be
invoked, but will always access the main thread globals using JIT_G.
This means that instead of freeing the JIT globals in the different
threads, the one in the main thread is freed repeatedly over and over,
crashing PHP. Fix it by always passing the pointer instead of relying on
JIT_G.
Closes GH-10835.
Fixes GH-10801
Named arguments are not supported by the constant evaluation routine, in
the sense that they are ignored. This causes two issues:
- It causes a crash because not all oplines belonging to the call are
removed, which results in SEND_VA{L,R} which should've been removed.
- It causes semantic issues (demonstrated in the test case).
This case never worked anyway, leading to crashes or incorrect behaviour,
so just prevent CTE of calls with named parameters for now.
We can choose to support it later, but introducing support for this in
a stable branch seems too dangerous.
This patch does not change the removal of SEND_* opcodes in remove_call
because the crash bug can't be triggered anymore with this patch as
there are no named parameters anymore and no variadic CTE functions
exist.
Closes GH-10811.
We need to carry around a reference to the underlying Bucket to be able to modify it by reference.
Closes GH-10749
Signed-off-by: George Peter Banyard <girgias@php.net>
Disable opcache.consistency_checks.
This feature does not work right now and leads to memory leaks and other
problems. For analysis and discussion see GH-8065. In GH-10624 it was
decided to disable the feature to prevent problems for end users.
If end users which to get some consistency guarantees, they can rely on
opcache.protect_memory.
Closes GH-10798.
Fixes GH-8646
See https://github.com/php/php-src/issues/8646 for thorough discussion.
Interned strings that hold class entries can get a corresponding slot in map_ptr for the CE cache.
map_ptr works like a bump allocator: there is a counter which increases to allocate the next slot in the map.
For class name strings in non-opcache we have:
- on startup: permanent + interned
- on request: interned
For class name strings in opcache we have:
- on startup: permanent + interned
- on request: either not interned at all, which we can ignore because they won't get a CE cache entry
or they were already permanent + interned
or we get a new permanent + interned string in the opcache persistence code
Notice that the map_ptr layout always has the permanent strings first, and the request strings after.
In non-opcache, a request string may get a slot in map_ptr, and that interned request string
gets destroyed at the end of the request. The corresponding map_ptr slot can thereafter never be used again.
This causes map_ptr to keep reallocating to larger and larger sizes.
We solve it as follows:
We can check whether we had any interned request strings, which only happens in non-opcache.
If we have any, we reset map_ptr to the last permanent string.
We can't lose any permanent strings because of map_ptr's layout.
Closes GH-10783.
Ilija Tovilo