While the case in bug #74429 is not documented and is only worky due to
an implementation bug, the strength seems to breach some real world
apps. Given this patch doesn't impact the initial security fix for
bug #74216, it is reasonable to let the apps keep working. As mentioned
in the ticket, this behavior is a subject to change in future versions
and should not be abused.
For historical reasons, fsockopen() accepts the port and hostname
separately: fsockopen('127.0.0.1', 80)
However, with the introdcution of stream transports in PHP 4.3,
it became possible to include the port in the hostname specifier:
fsockopen('127.0.0.1:80')
Or more formally: fsockopen('tcp://127.0.0.1:80')
Confusing results when these two forms are combined, however.
fsockopen('127.0.0.1:80', 443) results in fsockopen() attempting
to connect to '127.0.0.1:80:443' which any reasonable stack would
consider invalid.
Unfortunately, PHP parses the address looking for the first colon
(with special handling for IPv6, don't worry) and calls atoi()
from there. atoi() in turn, simply stops parsing at the first
non-numeric character and returns the value so far.
The end result is that the explicitly supplied port is treated
as ignored garbage, rather than producing an error.
This diff replaces atoi() with strtol() and inspects the
stop character. If additional "garbage" of any kind is found,
it fails and returns an error.
Hereby, interned strings are supported in thread safe PHP. The patch
implements two types of interned strings
- interning per process, strings are not freed till process end
- interning per request, strings are freed at request end
There is no runtime interning.
With Opcache, all the permanent iterned strings are copied into SHM on
startup, additional copying into SHM might happen on demand.
php_check_open_basedir() expects a local filesystem path,
but we're handing it a `glob://...` URI instead.
Move the check to after the path trim so that we're checking
a meaningful pathspec.
If this does not break the Unix system somehow, I'll be amazed. This should get most of it out, apologies for any errors this may cause on non-Windows ends which I cannot test atm.
If a userwrapper opener E_ERRORs then FG(user_stream_current_filename)
would remain set until the next request and would not be pointing
at unallocated memory.
Catch the bailout, clear the variable, then continue bailing.
Closes https://bugs.php.net/bug.php?id=73188
(cherry picked from commit 9f86cdaf7f)
If a userwrapper opener E_ERRORs then FG(user_stream_current_filename)
would remain set until the next request and would not be pointing
at unallocated memory.
Catch the bailout, clear the variable, then continue bailing.
Closes https://bugs.php.net/bug.php?id=73188
If a userwrapper opener E_ERRORs then FG(user_stream_current_filename)
would remain set until the next request and would not be pointing
at unallocated memory.
Catch the bailout, clear the variable, then continue bailing.
Closes https://bugs.php.net/bug.php?id=73188
If a userwrapper opener E_ERRORs then FG(user_stream_current_filename)
would remain set until the next request and would not be pointing
at unallocated memory.
Catch the bailout, clear the variable, then continue bailing.
Closes https://bugs.php.net/bug.php?id=73188
