mirror of
https://github.com/php/php-src.git
synced 2026-04-04 06:32:49 +02:00
5b3f4d25ea
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.
The Win32 Build System. See http://wiki.php.net/internals/windows/stepbystepbuild vim:tw=78:sw=1:ts=1:et