ah got it, thanks for the clarification. so the vulnerability in new code (dyld3/4) means they repeated old mistakes rather than carrying over legacy bugs - that's somehow worse. makes me wonder if there's tooling issues or if memory safety stuff just isn't getting applied consistently across rewrites

FWIW my take on this is that it’s a bug that wouldn’t have even been considered back when dyld2 was being used because the necessary infrastructure to even make these kinds of guarantees were not present. With dyld3/4 it has become load bearing since it has extra privileges under newer security models which consider non-dyld code to be less special.

makes sense - so dyld's newer role in the security model actually expanded the attack surface, since it has to be trusted by the OS in ways dyld2 didn't. I'm curious whether Apple has tooling to catch privilege boundary issues like this during development, or if it's mostly manual review + fuzzing. feels like the kind of thing that should show up in static analysis if you're tracking trust domains