If both the driver object and statement end up in the GC buffer and are
freed by the GC, then the destruction order is not deterministic and it
is possible that the driver object is freed before the statement. In
that case, accessing S->H will cause a UAF. As the resources are already
released we simply skip the destruction if the driver object is already
destroyed.
Fixed an issue where pdo_firebird float and double type values were wrong.
Changed from using `%F` format with `zend_strpprintf` to using `%H` format with
`zend_strpprintf_unchecked`.
Fixes GH-13119
Closes GH-13125
It turns out that the version of Firebird influences the test in terms
of supported data types. On Windows on 8.2 we seem to be using a
different version than on 8.1. Fix it by amending the test.
The core issue is still tested in the test, it's just that not all
datatypes are tested anymore (which isn't strictly necessary anyway).
The alignment of sqldata is in most cases only the basic alignment,
so the code type-puns it to a larger type, it *can* crash due to the
misaligned access. This is only an issue for types > 4 bytes because
every sensible system requires an alignment of at least 4 bytes for
allocated data.
Even though this patch uses memcpy, the compiler is smart enough to
optimise it to something more efficient, especially on x86.
This is just the usual approach to solve these alignment problems.
Actually, unaligned memory access is undefined behaviour, so even on x86
platforms, where the bug doesn't cause a crash, this can be problematic.
Furthermore, even though the issue talks about a 64-bit kernel and
32-bit userspace, this doesn't necessarily need to be the case to
trigger this crash.
Test was Co-authored-by: rvk01
Closes GH-10920.
Dialect 1 databases store and transfer `NUMERIC(15,2)` values as
doubles, which we need to cater to in `firebird_stmt_get_col()` to
avoid `ZEND_ASSUME(0)` to ever be triggered, since that may result
in undefined behavior.
Since adding a regression test would require to create a dialect 1
database, we go without it.
Closes GH-10021.
Using php_info_print_table_header() for "Foo: bar" looks odd and out of place,
because the whole line is colored. It is also questionable from a HTML
semantics point of view, because it does not described the columns that follow.
The use of this across extensions is inconsistent. It was part of the skeleton,
but ext/date or ext/json already use a regular row.
For columns of type `SQL_TEXT`, Firebird does not properly report the
actual column length, but rather only the maximum column length, so for
multi-byte encodings like UTF-8, such columns may have trailing
spaces. We work around that by treating such columns as `SQL_VARYING`
when we ask the server to describe the colum, what yields the desired
results.
Given that this is a work-around, and may break code which expects the
results with trailing spaces, we target "master" only.
Closes GH-8926.
On x86_64 glibc memrchr() uses SSE/AVX CPU extensions and works much
faster then naive loop. On x86 32-bit we still use inlined version.
memrchr() is a GNU extension. Its prototype becomes available when
<string.h> is included with defined _GNU_SOURCE macro. Previously, we
defined it in "php_config.h", but some sources may include <string.h>
befire it. To avod mess we also pass -D_GNU_SOURCE to C compiler.
* PHP-8.0:
Update NEWS
Fix#76448: Stack buffer overflow in firebird_info_cb
Fix#76449: SIGSEGV in firebird_handle_doer
Fix#76450: SIGSEGV in firebird_stmt_execute
Fix#76452: Crash while parsing blob data in firebird_fetch_blob
Fix#81122: SSRF bypass in FILTER_VALIDATE_URL
* PHP-7.4:
Update NEWS
Fix#76448: Stack buffer overflow in firebird_info_cb
Fix#76449: SIGSEGV in firebird_handle_doer
Fix#76450: SIGSEGV in firebird_stmt_execute
Fix#76452: Crash while parsing blob data in firebird_fetch_blob
Fix#81122: SSRF bypass in FILTER_VALIDATE_URL
* PHP-7.3:
Update NEWS
Fix#76448: Stack buffer overflow in firebird_info_cb
Fix#76449: SIGSEGV in firebird_handle_doer
Fix#76450: SIGSEGV in firebird_stmt_execute
Fix#76452: Crash while parsing blob data in firebird_fetch_blob
Fix#81122: SSRF bypass in FILTER_VALIDATE_URL
We need to verify that the `result_size` is not larger than our buffer,
and also should make sure that the `len` which is passed to
`isc_vax_integer()` has a permissible value; otherwise we bail out.
We need to verify that the `result_size` is not larger than our buffer,
and also should make sure that the `len` which is passed to
`isc_vax_integer()` has a permissible value; otherwise we bail out.
The tests leak memory, likely due to a slightly unclean shutdown of
libfbclient. To avoid failing CI, we disable LSan for all the tests.
Closes GH-6966.
This is meant to test against certain fixed responses of Firebird
servers. For now we add just a most basic test which verifies a
connection attempt.
Closes GH-6940.
1. Update: http://www.php.net/license/3_01.txt to https, as there is anyway server header "Location:" to https.
2. Update few license 3.0 to 3.01 as 3.0 states "php 5.1.1, 4.1.1, and earlier".
3. In some license comments is "at through the world-wide-web" while most is without "at", so deleted.
4. fixed indentation in some files before |
