RFC 2617 and 7616 describe that for the "Authorization" header we should
not put the qop nor nc value inside quotes. This differs from the
WWW-Authenticate header, which may have been the source of the confusion
in the implementation. While the version with quotes seems to work fine
in some cases, clearly not all servers accept the non-standard form.
To fix the issue, simply removing the quotes of those two header fields
of the client request to be in line with the RFC suffices.
I refer further to example 3.5 in RFC 2617 and example 3.9.1 in
RFC 7616.
RFC 2617: https://datatracker.ietf.org/doc/html/rfc2617
RFC 7616: https://datatracker.ietf.org/doc/html/rfc7616
Closes GH-14328.
This was only partially fixed in PHP-8.3. Backports and fixes the case for both
initialized and uninitialized property writes.
Fixes GH-14969
Closes GH-14971
Besides demonstrating the new behavior, this test also ensures that the
bundled and external libgd now behave the same. It has to be noted,
though, that we only test one of the five code paths.
Closes GH-14945.
According to the docs (https://www.php.net/manual/en/function.imagecreatefromwebp.php and https://www.php.net/manual/en/function.imagewebp.php), `false` should be returned on errors (similar to other functions of the `gd` extension), but actually all errors result in a `Fatal Error`. It doesn't look normal when trying to read an empty file or a file in the wrong format causes the program to stop. The problem seems to be related to a mega-patch that replaced `zend_error` with `zend_error_noreturn` almost everywhere. My patch fixes this behavior by switching from `zend_error_noerror` to `gd_error` (i.e. to `E_WARNING` level). All necessary memory cleanup is already in the code (as it was before the "zend_error_noreturn" patch).
Close GH-13774
The create_obj handler of InternalIterator is overwritten, but not the
clone_obj handler. This is not allowed.
In PHP 8.2 this didn't cause a segfault because the standard object
handler was used for the clone instead of the internal handler.
So then it allocates and frees the object using the standard object handlers.
In 8.3 however, the object is created using the standard object handler and
freed using the custom handler, resulting in the buffer overflow.
Even though bisect points to 1e1ea4f this only reveals the bug.
Closes GH-14882.
When dealing with a file, we must free the contents if the function
fails. While here, also fix the error message because previously it
sounded like the filename was too long while in fact the file itself
is too large.
Closes GH-14862.
`spl_object_storage_attach_handle` creates an entry already, but only
fills it in at the end with `spl_object_storage_create_element` which
allocates memory. In this case the allocation fails and we're left with
a NULL slot. Doing the allocation first isn't an option because we want
to check whether the slot is occupied before allocating memory.
The simplest solution is to set the entry to NULL and check for a NULL
pointer upon destruction.
Closes GH-14849.
libxml2 2.13 makes changes to how the parsing state is set, update our
code accordingly. In particular, it started reporting entities within
attributes, while it should only report entities inside text nodes.
Closes GH-14837.
This broke in 6318040df2 when phpdbg
stopped using its custom printing routines. By relying on standard
printing routines, the embedded NUL bytes are causing the strings to be
cut off, even when using %.*s. Solve this by going straight to the
output routine, which is what the printf routine would've done anyway.
Closes GH-14822.
It turns out that on a 32-bit system, this test can produce either the
"usual" expected output from the 64-bit test, OR the 32-bit-only
integer overflow message. We copy the dual expected outputs from
chunk_split_variation1_32bit.phpt to handle both cases.
This fixes an earlier commit that split the two tests based only on
the size of an int (32-bit versus 64-bit). The CI reveals that, at
least on a debug/zts build, the "64-bit" memory limit error (and not
the integer overflow error) is still produced.
The test in strings/wordwrap_memory_limit.phpt has a counterpart in
strings/wordwrap_memory_limit_win32.phpt. The two are conditional on
both the OS name and the size of an int (32- versus 64-bits).
A Gentoo Linux user has however reported that the 64-bit test fails on
a 32-bit system, with precisely the error message that the "win32"
test is expecting. I don't have any 32-bit hardware to test myself,
but I think it's reasonable to conclude that the OS name is not an
essential part of the test: it's simply 32- versus 64-bit.
This commit drops the conditionals for the OS name. Now one test will
be run on 32-bit systems, and the other on 64-bit systems, regardless
of the OS name.
Bug: https://bugs.gentoo.org/935382
In strings/chunk_split_variation1_32bit.phpt, we have a test that is
expected to fail on x32 with a possible integer overflow error. The
message reports the exact number of bytes -- a number big enough to
overflow an int on x32 -- stemming from a memory allocation in
chunk_split().
This number appears unpredictable, and is not the point of the test.
We replace it with %d to make the test independent of the allocation
details.
You cannot return or yield a reference to a nullsafe chain. This was
checked already in zend_compile_return but not yet in
zend_compile_yield.
Closes GH-14716.
Remove xmlErrMemory from the export section for Windows, this fixes the
build. Even though the original function was renamed [1] it is hidden,
so removing this should be sufficient and not be a BC break.
[1] 130436917c
Closes GH-14719.
The xinclude code from libxml removes the fallback node,
but the fallback node is still reference via $fallback.
The solution is to detach the nodes that are going to be removed in
advance.
Closes GH-14704.
Values retrieved from zend_getenv should be freed.
Note: The only possible value for `zend_getenv` is `sapi_getenv` which uses
zend alloc to duplicate the string that it reads from the SAPI module.
Closes GH-14708.
The error handling code isn't entirely right in two places.
One of the code blocks is dead because of an always-false condition, and
another code block is missing the assignment of a NULL pointer.
Getting the exact same behaviour is not entirely possible because you
can't extend the size of a shared memory region after it was made with
the Windows APIs we use, unless we destroy the region and recreate it,
but that has other consequences.
However, it certainly shouldn't crash.
Closes GH-14707.
is_zend_ptr() expected zend_mm_heap.huge_list to be circular, but it's in fact NULL-terminated. It could crash when at least one huge block exists and the ptr did not belong to any block.
