Fix buffer overflow in hash_pbkdf2() with a large output length

[lazerg]

hash_pbkdf2() sizes the digest buffer with ceil((float) length / 2.0) and the block count with ceil((float) digest_length / (float) ops->digest_size). A float carries 24 bits of mantissa, so past 2^24 the conversion rounds and both counts come out wrong: rounding up makes zend_bin2hex() write past the end of the return string, rounding down leaves the tail of the string uninitialized. hash_pbkdf2('md5', 'password', 'salt', 1, 268435473) writes 8 bytes out of bounds under ASAN.

Both counts are exact in integer arithmetic, so this replaces them with round-up divisions. <math.h> had no other user in the file.

This came out of #23377. The odd length case reported there is fine on its own, as Sjord noted before closing it: zend_string_alloc(length) reserves length + 1 bytes and 2 * ceil(length / 2) == length + 1, so the extra hexit lands on the terminator byte that gets overwritten a line later. The float conversion on those same two lines is a real overflow though.

[lazerg]

#23377 was closed since the odd-length case turned out fine. This PR fixes something else though, a float-precision overflow that causes a real out-of-bounds write for large output lengths. Reproduced it under ASAN. Still worth a review. @LamentXU123, mind taking a look when you get a chance?

[Sjord]

Nit: this gives a compiler warning (if I enable all warnings):

ext/hash/hash.c:1048:17: warning: conversion to ‘zend_long’ {aka ‘long int’} from ‘long unsigned int’ may change the sign of the result [-Wsign-conversion]
 1048 |         loops = (digest_length + ops->digest_size - 1) / ops->digest_size;
      |                 ^

It is not an actual problem, so I think it's fine.

[lazerg]

Agreed, it cannot bite here. digest_length is always at least 1 at that point: a negative length is rejected earlier, and 0 is replaced by the digest size. So the unsigned arithmetic cannot wrap, and the quotient always fits back into a zend_long. php-src does not build with -Wsign-conversion, so I left the line as it is. I can add an explicit cast if you would rather not see the warning.

[Sjord]

Looks good to me. Thanks for looking into the issue I made.