Fix GH-22060 and GH-22122: pin $this in zend_call_known_fcc

[iliaal]

Both reports are the same use-after-free: zend_call_known_fcc() ran the callback with fcc->object as $this without holding a reference, so a callback that released the last reference to its own receiver (autoloader self-unregistering, SQLite3 authorizer calling setAuthorizer(null)) freed it mid-call. Pinning the receiver across the call covers the autoloader and the sqlite3/pdo_sqlite authorizers, which all dispatch through it.

[DanielEScherzer]

okay for ext/reflection, don't know about the other parts

[Girgias]

I was trying to understand why we would need to add ref the fcc.object, and my understanding is that it represents the $this value, so I guess this is valid.

However, we are once again fixing bugs and affecting performance for idiosyncratic code. I would rather prefer a solution that bans unsetting such callables within the calls. Similar to a fix we recently did for an unserialising routine in SPL.

[iliaal]

Pinning is two refcount ops against a full call-frame setup, so the per-call cost is negligible. Banning is the bigger change: the autoload loop is deliberately built to allow add/remove mid-iteration, and disabling the authorizer mid-call is a one-shot the sqlite3 test relies on. Turning either into a thrown error is a behavior change that can't go in a stable branch. If the stricter semantics are worth having, that's a master-only follow-up.

[iluuu1994]

However, we are once again fixing bugs and affecting performance for idiosyncratic code.

Such things will come up more and more with the raise of AI.

A while ago when fixing a similar issue, @TimWolla asked me if zend_call_function() should just take care of at least making sure $this survives. I think that's reasonable, and something that could be changed on master. In that case, we should remove immediate add/delref around zend_call_function() calls throughout the codebase.

This should target master anyway (we agreed to not fixing such bugs on stable branches that are unlikely to cause issues in the real world). So maybe let's just go with the above instead.

[iliaal]

First part's done: zend_call_function() now pins fci_cache->object across the call, and I've retargeted this to master. It covers both reports, since the autoloader and the sqlite3/pdo_sqlite authorizers all dispatch through it.

On removing the add/delref throughout the codebase: most of them can't go. The pin is released when the call returns, so it only guarantees $this for the call itself, not for code the caller runs afterward. zend_std_unset_property() is the clear case: it does (*guard) &= ~IN_UNSET after the unsetter returns, with guard pointing into the object, so dropping that GC_ADDREF brings back a UAF on the guard reset. The pure call-survival ones like Countable::count could go, but that's a separate cleanup. Kept this PR to the pin plus tests.