The issue referenced here doesn't contain a reproducer, but I recently
received an email of a user with the exact same problem. I was able to
recreate the scenario locally using vsftpd and setting
`require_ssl_reuse=YES` in the vsftpd configuration.
It turns out that our session resumption code is broken. It only works a
single time: the first time a data connection opens. Subsequent data
connections fail to reuse the session. This is because on every data
connection a new session is negotiated, but the current code always
tries to reuse the (stale) session of the control connection.
To fix this, we use SSL_CTX_sess_set_new_cb() to setup a callback that
gets called every time a new session is negotiated. We take a strong
reference using SSL_get1_session() and store it in the ftpbuf_t struct.
Every time we open a data connection we'll take that session.
This works because every control connection has at most a single
associated data connection.
Also disable internal session caching storage to not fill the cache up
with useless sessions.
There is no phpt for this because PHP does not support enforcing SSL
session reuse.
It is however testable manually by setting up vsftpd and setting the
`require_ssl_reuse=YES` function from before.
Closes GH-12851.
This regressed in cd53ce838a.
The loop with `zend_hash_iterators_update` hangs forever because
`iter_pos` can't advance to idx. This is because the
`zend_hash_iterators_lower_pos` upper bound is `target->nNumUsed`,
but that is set to `source->nNumOfElements`.
That means that if there are holes in the array, we still loop over all
the buckets but the number of bucket slots will not match.
Fix it by changing the assignment.
Closes GH-12831.
If there are two users that can execute the script that caches a WSDL,
but the script is owned by a single user, then the caching code will
name the cached file with the file owner username and a hash of the uri.
When one of the two tries to rename the file created by the other
process, this does not work because it has no permission to do so.
This then leaves temporary files floating in the temp directory.
To fix the immediate problem, unlink the file after rename has failed.
On the long term, this has to be fixed by taking the username of the
process instead of the username of the file owner.
Closes GH-12841.
php_strip_url_passwd modifies url in-place. We cannot assume from
php_message_handler_for_zend that data is a temporary, modifiable string.
Fixes oss-fuzz #64209
Closes GH-12733
The namespace data is freed and set to NULL, but there remain references
to the namespace declaration nodes. This (rightfully) confuses libxml2
because its invariants are broken. We also have to remove all remaining
references from the subtree. This fixes the data corruption bug.
Closes GH-12681.
Have to use file_put_contents() instead of --FILE-- because we have to
actually load it using the exec command, *and* have to make multiple
files, and note that we can only load files relative from the current
directory, so we can't rely on files being in the sapi/phpdbg/tests
folder.
Closes GH-12680.
The temporary HashTable has a destructor that releases the string held
by the entry's value. However, browscap_intern_str(_ci) only incremented
the refcount for the reference created by the return value. As the
HashTable is only used during parsing, we don't need to manage the
reference count of the value anyway, so get rid of the destructor.
This is triggerable in two cases:
- When using php_admin_value to set the ini at the activation stage
- When running out of space for the opcache-interned strings
Closes GH-12634.
These two might not be available everywhere so we check them in
config.m4 when doing the configure step. Check is skipped for musl libc
due to limited implementation.
Constants that are defined into main/php_config.h:
HAVE_FPATHCONF
HAVE_PATHCONF
Implemented via GH-10238
Related to GH-10350
Fixes GH-12725
php_strip_url_passwd modifies url in-place. We cannot assume from
php_message_handler_for_zend that data is a temporary, modifiable string.
Fixes oss-fuzz #64209
Closes GH-12733
