A correct implementation would be to just call glibc directly, this seems like a hasty fix to get the patch out the door. The history of vulns from bad shell escaping is as old as bash, whenever possible you probably shouldn't be mixing code and data, especially in a security critical application like this.
The fact that there is no portable way to link the relevant functions that works reliably across all distributions of Linux is a failure of POSIX and GNU, and unfortunately is largely the Linux distribution story in a nutshell.
Your answer is mostly correct, except that when you tug on that thread the shelf comes off the wall, the plaster comes with it, and then it cracks the water pipes on the way to the floor.
likely intended more as a lint than a security feature, it's not unusual to want to exclude commonly misused features from your code and any libraries you use.
Knowing the mess that is the php standard library, I imagine many applications would want to just straight up ban the really bad parts.
from a quick skim, it looks like the underlying bug is just not handling object resurrection[1] at all (FreeMe adds a reference to $array while its destructor is called).
I'm not really familiar with PHP but this seems like a surprising oversight for a popular language. Does PHP just not care about memory corruption? The fact that it is this easy is far more surprising than it being used to circumvent a questionable security feature.
Its been a while since I've touched this stuff but my recollection is the ELF interpreter (ldso, not the kernel) is responsible for everything after mapping the initial ELF's segments.
iirc execve maps pt_load segments from the program header, populates the aux vector on the stack, and jump straight to the ELF interpreter's entry point. Any linked objects are loaded in userspace by the elf interpreter. The kernel has no knowledge of the PLT/GOT.
Especially relevant for dynamic linkers is the AT_PHDR and AT_BASE auxiliary vector entries which provide the address of the executable's program header table and the address of the interpreter, respectively.
