Although the issue was demonstrated using Curl, the issue is purely in
the streams layer of PHP.
Full analysis is written in GH-11078 [1], but here is the brief version:
Here's what actually happens:
1) We're creating a FILE handle from a stream using the casting mechanism.
This will create a cookie-based FILE handle using funopen.
2) We're reading stream data using fread from the userspace stream. This will
temporarily set a buffer into a field _bf.base [2]. This buffer is now equal
to the upload buffer that Curl allocated and note that that buffer is owned
by Curl.
3) The fatal error occurs and we bail out from the fread function, notice how
the reset code is never executed and so the buffer will still point to
Curl's upload buffer instead of FILE's own buffer [3].
4) The resources are destroyed, this includes our opened stream and because the
FILE handle is cached, it gets destroyed as well.
In fact, the stream code calls through fclose on purpose in this case.
5) The fclose code frees the _bs.base buffer [4].
However, this is not the buffer that FILE owns but the one that Curl owns
because it isn't reset properly due to the bailout!
6) The objects are getting destroyed, and so the curl free logic is invoked.
When Curl tries to gracefully clean up, it tries to free the buffer.
But that buffer is actually already freed mistakingly by the C library!
This also explains why we can't reproduce it on Linux: this bizarre buffer
swapping only happens on macOS and BSD, not on Linux.
To solve this, we switch to an unbuffered mode for cookie-based FILEs.
This avoids any stateful problems related to buffers especially when the
bailout mechanism triggers. As streams have their own buffering
mechanism, I don't expect this to impact performance.
[1] https://github.com/php/php-src/issues/11078#issuecomment-2155616843
[2] 5e566be7a7/stdio/FreeBSD/fread.c (L102-L103)
[3] 5e566be7a7/stdio/FreeBSD/fread.c (L117)
[4] 5e566be7a7/stdio/FreeBSD/fclose.c (L66-L67)
Closes GH-14524.
We should not early-out with success status if we found an ipv6
hostname, we should keep checking the rest of the conditions.
Because integrating the if-check of the ipv6 hostname in the
"Validate domain" if-check made the code hard to read, I extracted the
condition out to a separate function. This also required to make
a few pointers const in order to have some clean code.
The old code checked for suffixes but didn't take into account trailing
whitespace. Furthermore, there is peculiar behaviour with trailing dots
too. This all happens because of the special path-handling code inside
CreateProcessW.
By studying Wine's code, we can see that CreateProcessInternalW calls
get_file_name [1] in our case because we haven't provided an application
name. That code gets the first whitespace-delimited string into app_name
excluding the quotes. It's then passed to create_process_params [2]
where there is the path handling code that transforms the command line
argument to an image path [3]. Inside Wine, the extension check if
performed after these transformations [4]. By doing the same thing in
PHP we match the behaviour and can properly match the extension even in
the given edge cases.
[1] 166895ae3a/dlls/kernelbase/process.c (L542-L543)
[2] 166895ae3a/dlls/kernelbase/process.c (L565)
[3] 166895ae3a/dlls/kernelbase/process.c (L150-L151)
[4] 166895ae3a/dlls/kernelbase/process.c (L647-L654)
* Remove usage of SDWORD, replace with SQLINTEGER
Some different driver managers disagree if this should be 4 or 8 bytes
in size. SQLGetDiagRec expects this to be an SQLINTEGER, so we should
just use that explicitly instead of hoping that it's the same size.
Fixes GH-14367
* Replace SWORD with SQLSMALLINT
While this hasn't caused issues like the SQLINTEGER/SDWORD confusion
has, we should use what SQLDescrimeParam calls for, which is
SQLSMALLINT.
Although the issue mentioned FreeBSD, this is a broader problem:
the current ARM64 code to load the TLS offset assumes a setup with
the non-default TLS model. This problem can also apply on some
configurations on other platforms.
Closes GH-11236.
There's a hash table that maps type names to class name, but names with
a leading backslash are not supported. The engine has logic to strip
away the leading backslash that we should replicate here.
It works by checking if we need to make an actual copy in case an
unexpected (e.g. invalid data or leading backslash) situations are
detected. Upon making a copy we normalize the data in the table.
Furthermore, previously the code assumed that the key was always valid
and that the structure was a non-packed hash table. This isn't
necessarily the case. The new code fixes this as well.
Closes GH-14398.
There's a few leaks where the string is copied for lowercasing but not released.
Where possible, use the _lc functionality of zend_hash to do the lookup
to avoid the leaks that currently exist with the manual lowercasing.
Closes GH-14390.
zend_ini_long() actually expects the length without the NUL byte, but
we're passing the length *with* the NUL byte. This mess can actually be
avoided altogether by using INI_INT, so use that instead.
Closes GH-14382.
This partially backports that PR to stable branches as it has been in master
without reported problems so far.
It's only a partial backport because the stable branches don't have the
ZTS persistent resource fix that would fix shutdown crashes, i.e. the
code change in mysqlnd_vio's close_stream is not backported.
This is fully fixed on master.
Closes GH-14324.
Closes GH-10599.
The naming of the userland functions is terrible and confused me.
gzdecode() is actually the function to decompress a gzip stream, and
gzuncompress() is the one to decompress a deflate stream...
See zlib.c to see the internal function -> type mapping.
If there is no root, the namespace cannot be attached to it,
so we have to attach it to the old list.
This isn't a problem in "new DOM" because namespaces are managed in a
separate structure there.
