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 original code is error-prone due to the "best fit mapping" that
happens with the argument parsing but not with the query string.
When we get a non-ASCII character, try to remap it and see if it becomes
a hyphen.
An alternative approach is to create a custom main `wmain` receiving
wide-character variations that does the ANSI transformation with the
best-fit mapping, but that's more error-prone and could cause unexpected
breakage.
Another alternative was just don't doing this check altogether and
always check for `cgi || fastcgi` instead, but that breaks real-world
use-cases.
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.
