Delaying error handlers

[arnaud-lb]

Description

Due to error handlers, some operations may have unsuspected effects. This is the cause of bugs and workarounds. Quoting GH-6903:

[...] long-standing source of interrupt
vulnerabilities: A notice is emitted during execution of an opcode,
resulting in an error handling being run. The error handler modifies
some data structure the opcode is working on, resulting in UAF or
other memory corruption.

These bugs and workarounds could be avoided by delaying error handlers until a safepoint. Existing/Previous work:

• Delay notice emission until end of opcode #6903
• An attempt to fix all the failures to clobber data by user error hand… #7735
• Delay notice emission until end of opcode #12090
• Delayed notice again #12805

I'm creating this ticket to aggregate issues that would not exist with delayed error handlers:

• Array assignment fails when the array has been resized in error handler #13754
• Assertion failure in Zend/zend_compile.c #15907
• Heap Use-After-Free (UAF) Bug in PHP #16726
• Assertion failure Zend/zend_hash.c:1543 #17416
• ternary reference assignment should be legal #18043
• assertion failure spl_fixedarray #18274
• SEGV array.c #20042
• Assertion failure in zend_hash_del with HashTable refcount inconsistency #20855
• UBSan: member access within null pointer of type 'zend_object' in ext/standard/var.c:185 via var_dump() #21024
• heap use after free zend_execute.h:195 #21245

[ndossche]

Another interesting, potentially less invasive fix, is to detect clobbering: #7735

[arnaud-lb]

I like this approach, but is has the following drawbacks:

• It needs fatal errors / longjmp
• Not all error handler issues are UAFs. For example Assertion failure Zend/zend_hash.c:1543 #17416 and Array assignment fails when the array has been resized in error handler #13754