Fix GH-16590: UAF in session_encode() - #16640

I'm always a fan of plugging UAF issues, so I have no problem with this unless @SakiTakamachi or @NattyNarwhal see something here that I don't.

I don't think there is a practical ABI break (okay, the _zv variable may be used in the code, and there's a memory leak in case that code returns). The more relevant problem I see is that extensions which will not be rebuilt after this patch, will not profit from it. But even that doesn't appear to be a real issue ("malicious code").

I think this is good to merge to earlier releases too. I don't think it's an ABI break for the reasons Christoph outlined.

Maybe not per se ABI break, but it is an API break at least. A third party extension that uses PS_ENCODE_LOOP and uses return in the loop will suddenly have to change their code to not leak memory.

Maybe not per se ABI break, but it is an API break at least. A third party extension that uses PS_ENCODE_LOOP and uses return in the loop will suddenly have to change their code to not leak memory.

I tried to look for users of PS_ENCODE_LOOP on GitHub (Not a perfect strategy, not everything is on GitHub). The only external user I could find was Susohin, which did do an early return. That's also PHP 5, so... (Well, WDDX is also a user, but it uses it very trivially and it's a former member of ext/.)

Seems like there's not really a problem for the RMs to go lower than 8.4, but I will only push it to 8.4 because of the theoretical break and the fact that users are unlikely to encounter this anyway. If really necessary, it can always be backported.