It's great to see this bug being fixed. Unfortunately the patch is flawed.
In the recv loop (line 1829-1845 in my bug report) `size' can be incremented at two places. Once at `size += rcvd' and also at `size++'. This means that `size' can be incremented by more than `rcvd' per iteration, which results in the added overflow check being bypassable.
`size' can be incremented by at most `rcvd * 2' per iteration, which is the reason my previously suggested fix uses `rcvd * 2' and not only `rcvd'.
To properly fix the bug I suggest - in addition to the overflow check already in existence - removing the else branch, that increments `size' by one, resulting in `size' only being increased by `rcvd' or less per iteration and thus ensuring the overflow check can't be bypassed.
It's also worth noting that said branch isn't necessary for the workings of the function and just needlessly complicates it.
Regards,
Max Spelsberg
==
@@ -1663,8 +1663,6 @@ ftp_genlist(ftpbuf_t *ftp, const char *cmd, const char *path TSRMLS_DC)
for (ptr = data->buf; rcvd; rcvd--, ptr++) {
if (*ptr == '\n' && lastch == '\r') {
lines++;
- } else {
- size++;
}
lastch = *ptr;
}

I concur with the comment above - the fix seems incorrect / incomplete, because input characters are counted twice. That also reduces amount of data malicious FTP server needs to send to trigger this bug in unpatched PHP versions. Malicious sever in the report sends 4G of data, but half of that is sufficient.
As the applied patch changed types from int to size_t, so the incomplete fix problem is only relevant on 32bit platforms.
Alternative to dropping else branch is to drop size += rcvd; as that counts \n following \r, which do not need to be counted.
Anyone backporting fix to older PHP versions should ensure 8f4a6d6 is also backported.