base64_decode: remove redundant code

case 1 is already handled in the first lines of the for loop;
it would only be entered in the invalid case where the string
continues past the de

base64_decode: remove redundant code

case 1 is already handled in the first lines of the for loop;
it would only be entered in the invalid case where the string
continues past the defined length (ch != 0 but length-- == 0).

case 2 and case 3 are redundant, since k >= j and later the
string is truncated to j characters anyway.

show more ...

base64_decode: fix bug #72263 (skips char after padding)

base64_decode: fix bug #72152 (fail on NUL bytes in strict mode)

This added check is actually for NOT failing in NON-strict mode.
The ch == -2 check later causes the desired failure in s

base64_decode: fix bug #72152 (fail on NUL bytes in strict mode)

This added check is actually for NOT failing in NON-strict mode.
The ch == -2 check later causes the desired failure in strict mode.

show more ...

base64_decode: remove redundant check

If length == 0 || *current != '=' is false, the for loop will always
end up in this same point, until the if statement becomes true.
Thus, the i

base64_decode: remove redundant check

If length == 0 || *current != '=' is false, the for loop will always
end up in this same point, until the if statement becomes true.
Thus, the if statement is not needed.

show more ...

base64_decode: reorder to fix out of bounds read

Merge branch 'PHP-5.6' into PHP-7.0

* PHP-5.6:
Happy new year (Update copyright to 2016)

Happy new year (Update copyright to 2016)

Use ZSTR_ API to access zend_string elements (this is just renaming without semantick changes).

bump year

bump year

first shot remove TSRMLS_* things

s/PHP 5/PHP 7/

remove useless check

first show to make 's' work with size_t

master renames phase 3

master renames phase 1

several fixes -

- param parsing Z_PARAM_STR vs Z_PARAM_STRING
- some functions for new params
- etc

Refactor base64 to returning zend_string

Use better data structures (incomplete)

Bump year

Happy New Year

Fix memory allocation checks for base64 encode

base64_encode used safe_emalloc, but one of the arguments was derived from a
multiplication, thus making the allocation unsafe again.

Fix memory allocation checks for base64 encode

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.

show more ...

- Year++

Fixed bug #55273 (base64_decode() with strict rejects whitespace after pad)

- Year++