A recent commit[1] which fixed a memory leak introduced a regression
regarding the formerly liberal handling of IP addresses to bind to. We
fix this by reverting that commit, and fix the memory leak where it
actually occurs. In other words, this fix is less intrusive than the
former fix.
[1] <http://git.php.net/?p=php-src.git;a=commit;h=0b8c83f5936581942715d14883cdebddc18bad30>
Closes GH-6104.
This is actually about three distinct issues:
* If an empty string is passed as $address to `stream_socket_sendto()`,
the `sa` is not initialized, so we must not pass it as `addr` to
`php_stream_xport_sendto()`.
* On POSIX, `recvfrom()` truncates messages which are too long to fit
into the specified buffer (unless `MSG_PEEK` is given), discards the
excessive bytes, and returns the buffer length. On Windows, the same
happens, but `recvfrom()` returns `SOCKET_ERROR` with the error code
`WSAEMSGSIZE`. We have to catch this for best POSIX compatibility.
* In `php_network_parse_network_address_with_port()`, we have to zero
`in6` (not only its alias `sa`) to properly support IPv6.
Co-Authored-By: Nikita Popov <nikita.ppv@googlemail.com>
The $Id$ keywords were used in Subversion where they can be substituted
with filename, last revision number change, last changed date, and last
user who changed it.
In Git this functionality is different and can be done with Git attribute
ident. These need to be defined manually for each file in the
.gitattributes file and are afterwards replaced with 40-character
hexadecimal blob object name which is based only on the particular file
contents.
This patch simplifies handling of $Id$ keywords by removing them since
they are not used anymore.
Prohibit direct update of GC_REFCOUNT(), GC_SET_REFCOUNT(), GC_ADDREF() and GC_DELREF() shoukf be instead.
Added mactros to validate reference-counting (disabled for now).
These macros are going to be used to eliminate race-condintions during reference-counting on data shared between threads.
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.
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.
