Repository navigation
Delaying error handlers #20018
Description
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) in set_error_handler() reentrancy #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
- Heap use-after-free in array assignment (ZEND_ASSIGN_DIM) via re-entrant user output handler during __destruct() #20482
- 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
Reacted by Ilija Tovilo
Activity
ndossche commentedon Oct 1, 2025
Another interesting, potentially less invasive fix, is to detect clobbering: #7735
arnaud-lb commentedon Oct 1, 2025
I like this approach, but is has the following drawbacks:
Defer user error handlers raised from user-code opcodes