Fix it by extending the array sizes by one character. As the input is
limited to the maximum path length, there will always be place to append
the slash. As the php_check_specific_open_basedir() simply uses the
strings to compare against each other, no new failures related to too
long paths are introduced.
We'll let the DOM and XML case handle a potentially too long path in the
library code.
PHP’s implementation of crypt_blowfish differs from the upstream Openwall
version by adding a “PHP Hack”, which allows one to cut short the BCrypt salt
by including a `$` character within the characters that represent the salt.
Hashes that are affected by the “PHP Hack” may erroneously validate any
password as valid when used with `password_verify` and when comparing the
return value of `crypt()` against the input.
The PHP Hack exists since the first version of PHP’s own crypt_blowfish
implementation that was added in 1e820eca02.
No clear reason is given for the PHP Hack’s existence. This commit removes it,
because BCrypt hashes containing a `$` character in their salt are not valid
BCrypt hashes.
We must not instantiate the object prior checking error conditions
Moreover, we need to release the HUGE amount of memory for files which are over 4GB when throwing a ValueError
Closes GH-10545
copy_file_range can return early without copying all the data. This is
legal behaviour and worked properly, unless the mmap fallback was used.
The mmap fallback would read too much data into the destination,
corrupting the destination file. Furthermore, if the mmap fallback would
fail and have to fallback to the regular file copying mechanism, a
similar issue would occur because both maxlen and haveread are modified.
Furthermore, there was a mmap-resource in one of the failure paths of
the mmap fallback code.
This patch fixes these issues. This also adds regression tests using the
new copy_file_range early-return simulation added in the previous
commit.
Commit a21195650e added a TSRM destructor, but that destructor
will get called by tsrm_shutdown(), which is after opcache.so has
already been unloaded, resulting in a shutdown crash, e.g.:
#0 0x00007fad01737500 in ?? ()
#1 0x000055ac54e723c4 in tsrm_shutdown () at TSRM/TSRM.c:194
#2 0x000055ac54c42180 in main (argc=80, argv=0x55ac57bc14d0) at sapi/cli/php_cli.c:1388
By calling ts_free_id() before opcache.so gets unloaded, we can easily
fix this crash bug.
* ext/opcache/zend_jit: cast function to fix -Wincompatible-pointer-types
Regression by commit a21195650e
* TSRM/win32: fix ts_allocate_dtor cast
The dtor was casted to ts_allocate_ctor; luckily, ts_allocate_dtor and
ts_allocate_ctor just happen to be the same type.
(And any PECLs returning `zend_empty_array` in the handler->get_properties
overrides)
Closes GH-9697
This is similar to the fix used in d9651a9419
for array_walk.
This should make it safer for php-src (and PECLs, long-term) to return
the empty immutable array in `handler->get_properties` to avoid wasting memory.
See https://github.com/php/php-src/issues/9697#issuecomment-1273613175
The only possible internal iterator position for the empty array is at the end
of the empty array (nInternalPointer=0).
The `zend_hash*del*` helpers will always set nInternalPointer to 0 when an
array becomes empty,
regardless of previous insertions/deletions/updates to the array.
The entry.flags was used to check whether the entry has the directory
flag. The flags however were masked to only contain the permissions. We
need to check the mode, before the permission masking, instead of the
flags to check whether it is a directory.
Closes GH-10464
Signed-off-by: George Peter Banyard <girgias@php.net>
memsize is a signed long, therefore the check against the
(*un*signed long maximum) / 1024² will allow too large values. This check worked
correctly in d4b3f89c53 where it checked against the maximum signed
value, but was broken in 003346c450. Fix it by changing ZEND_ULONG_MAX
to ZEND_LONG_MAX.
The condition `code == 0x0450 || code == 0x045D` is always false because
of an incorrect range check on code.
According to the BMP coverage in the encoding spec for ISO-8859-5
(https://encoding.spec.whatwg.org/iso-8859-5-bmp.html) the range of
valid characters is 0x0401 - 0x045F (except for 0x040D, 0x0450, 0x045D).
The current check has an upper bound of 0x044F instead of 0x045F.
Fix this by changing the upper bound.
Closes GH-10399
Signed-off-by: George Peter Banyard <girgias@php.net>
The current check always evaluated to false because if `!page_size`
is true, then `page_size & (page_size - 1)` equals `0 & (0 - 1)` which
is always 0. The if condition is meant to check if page_size is zero or
not a power of two, thus we must change the AND to an OR to fix this
issue.
Closes GH-10427
Signed-off-by: George Peter Banyard <girgias@php.net>
When a uint8_t is bitshifted to the left, it is actually promoted to an
int. For the current code this has the effect of a wrong sign-extension,
and the result will also wrongly become zero when insert_pos >= 32.
Fix this by adding an explicit cast.
Furthermore, the partial prefix byte mask was computed incorrectly: the
byte is already shifted so the mask should not account for the shift.
This effectively reverts #8984.
As discussed in #10327 which will enable the use of the getrandom(2) syscall on
NetBSD instead of relying on the userland arc4random_buf(), the CSPRNG should
prioritize security over speed [1] and history has shown that userland
implementations unavoidably fall short on the security side. In fact the glibc
implementation is a thin wrapper around the syscall due to security concerns
and thus does not provide any benefit over just calling getrandom(2) ourselves.
Even without any performance optimizations the CSPRNG should be plenty fast for
the vast majority of applications, because they often only need a few bytes of
randomness to generate a session ID. If speed is desired, the OO API offers
faster, but non-cryptographically secure engines.
The assertion failure was triggered in a debug code-path that validates
property types for internal classes.
zend_verify_internal_read_property_type was called with retval being a
reference, which is not allowed because that function eventually calls to
i_zend_check_property_type, which does not expect a reference.
The non-debug code-path already takes into account that retval can be a
reference, as it optionally dereferences retval.
Add a dereference in zend_verify_internal_read_property_type just before
the call to zend_verify_property_type, which is how other callers often
behave as well.
When this INI option is enabled, it reverts the line separator for
headers and message to LF which was a non conformant behavior in PHP 7.
It is done because some non conformant MTAs fail to parse CRLF line
separator for headers and body.
This is used for mail and mb_send_mail functions.
