The buffer size was calculated manually, thus creating integer overflows
for very large inputs, e.g. nl2br(str_repeat("\n", 613566757)).
The code now uses safe_emalloc, thus making the code throw an error
instead of crashing.
The code was already using safe_emalloc but did the multiplication in
the first argument, thus making the use of safe_emalloc pretty useless.
The *2 is now moved to the second argument.
Use salt_len_in instead of strlen(salt) or PHP_MAX_SALT_LEN, otherwise too
much memory will be allocated.
sha512 has a 86 character checksum, not 43. That probably was a copy&paste
from the sha256 code which indeed has 43.
The allocation also was using sizeof(char *), thus allocating 4 or 8 times
as much memory as necessary. The sizeof(char *) was removed in the 5.4
branch in b7a92c9 but forgotten on 5.3.
The memset 0 call was using PHP_MAX_SALT_LEN which can be smaller than the
output buffer and thus not zeroing out everything. Use the size of the
output buffer (needed) instead.
base64_encode used safe_emalloc, but one of the arguments was derived from a
multiplication, thus making the allocation unsafe again.
There was a size check in place, but it was off by a factor of two as it
didn't account for the signedness of the integer type.
The unsafe allocation is not exploitable, but still causes funny behavior
when the sized overflows into a negative number.
To fix the issue the *4 factor is moved into the size argument (where it is
known to be safe), so safe_emalloc can carry out the multiplication.
The size check is removed as it doesn't really make sense once safe_emalloc
works correctly. (Would only cause base64_encode to silently return false
instead of throwing an error. Also could cause problems with other uses of
the base64 encoding API, which all don't check for a NULL return value.)
Furthermore the (length + 2) < 0 check is replaced with just length < 0.
Allowing lengths -2 and -1 doesn't make sense semantically and also is not
honored in the following code (negative length would access unallocated
memory.)
Actually the length < 0 check doesn't make sense altogether, but I left it
there just to be safe.
Modify the scanner to check if the first char of the raw data is an opening " in which case we
need to find the closing one. Otherwise just search for the next end of value char [\r\n;\000]
What happens here is trivial long overflow. Despite the bug attracted
attention on windows, the same story is on linux. Just wait for a big
anough bucket->key . The linux test had %i to check the key value
which should be %d all the way.
There is a logic error in charset detection part for htmlentities.
When mbstring is compiled shared and mbstring.internal_encoding
is set to pass, it prevents default_charset from being checked
resulting iso-8859-1 being choosed.
After pushed, I found the test script in 5.4 is already fixed this, so
revert this change, and be consistent with 5.4's test
This reverts commit 24d85e4bd8, reversing
changes made to bae56a87f8.
Headers: forbid \r and \n also after \0, allow CRLF followed by HT or SP and forbid \0. See bug #60227.
Conflicts:
ext/standard/tests/general_functions/bug60227.phpt
ext/standard/tests/general_functions/bug60227_1.phpt
ext/standard/tests/general_functions/bug60227_2.phpt
main/SAPI.c
