This is caused by the fix for #72633. Namely, lastval() throws an error,
if no nextval() was called earlier in the same session. This is by all
means correct so far, however inside a transaction it leads to an abort.
This is the opposite to MySQL's last_insert_id() which doesn't produce
any error no matter something were autoincremented or not.
To avoid existing scripts breakage in the stable branches, the previous
patch is extended to revert the transaction to the state before the lastval()
call in case of error. It is done only for 5.6 and 7.0 to retain BC. For 7.1+,
the clean behavior should persist. This is already the current behavior, when
the sequence name is explicitly passed. So there's no reason to obfuscate the
errors where this breakage is valid.
Many FTP-S servers now require FTP clients to re-use the SSL session
from the control connection on the data connection, to prove that the
same entity controls both connections. This patch updates PHP's FTP-S
client code to allow that possibility.
getimagesize() is rather strict about the length of the marker payload data,
and fails if there are extraneous bytes before the next marker. Only a very
special case reported in bug #13213 is catered to.
libjpeg is rather resilient to such corrupted JPEG files, and raises a
recoverable error in this case. Other image processors also accept such
JPEG files, so we adapt getimagesize() to skip (but warn about) such
extraneous bytes.
The has_property handler only checked whether a respective column name
exists, but neither whether the column value is set, nor whether it is
empty, respectively. We fix that to match the behavior of POD:FETCH_OBJ in
particular and PHP in general.
Also initialize buffer and buffer2 to NULL, which should fix bug #72039 (Use of uninitialised value on mssql_guid_string).
This only applies to 5.6, as we do not have mssql in 7.0 anymore
Before this patch, exif_process_IFD_in_MAKERNOTE() would return false, then causing the rest of the EXIF parsing to be interrupted. This is a regression from earlier which was most likely a part of a security fix for MAKERNOTE.
The new behavior is to instead of stopping to parse, to continue so we can still fetch data like thumbnail and GPS, thrus allowing yet unsupported formats to parse. If EXIF's debugging mode is enabled, a notice will display in case we do not match against a valid MAKERNOTE signature.
This should temporarily fix bug #72682 (exif_read_data() fails to read all data for some images) until I get around to debug it further.
(cherry picked from commit aabcb5481d)
Calling imagesetstyle() with an empty $styles array caused gdImageSetStyle()
to be called with `noOfPixels==0`, what could have lead to OOB reads.
Actually, this issue will be fixed in libgd, but to avoid issues when older
libgd is in use, we simply disallow passing an empty $styles array to
imagesetstyle(), what wouldn't serve a useful purpose anyway.
This reverts commit 14d674442e.
I misread the discussion on the bug -- this is not the correct
fix. However the other proposed fix does not work either, so just
reverting for now.
Julian days < 347998 denote invalid Jewish calendar dates, so
cal_from_jd($jd, CAL_JEWISH) and jdmonthname($jd, CAL_MONTH_JEWISH) should
actually fail. For BC we don't yet let them though, but we fix the OOB read
that happens in this case, and we also adjust cal_from_jd()'s return value
to have empty strings for "abbrevdayname" and "dayname" instead of "Sun"/
"Sunday" and NULL for "dow" instead of 0, which doesn't make any sense.
