Fix GH-21368 crash: runtime orig_handler lookup in escape_if_undef

[iliaal]

Follow-up to #21368.

@vibbow reported an access violation in zend_jit_escape_if_undef on
PHP 8.5.5 VS17 x64 NTS (Windows + IIS + FastCGI), crashing at the fix
I introduced in #21368:

FAILURE_BUCKET_ID: INVALID_POINTER_READ_c0000005_php8.dll!zend_jit_escape_if_undef
FAULTING_SOURCE_LINE_NUMBER: 7980

The crashing instruction is mov rcx, [rax+rcx*8+0xD0], reading 0xD0
from a heap address that isn't mapped. On 64-bit NTS that offset
corresponds to zend_op_array->reserved[zend_func_info_rid], which is
what ZEND_FUNC_INFO(op_array) expands to.

Root cause

#21368 dispatched to orig_handler via a compile-time load computed
from exit_info->op_array. That pointer is set at parent-trace compile
time from JIT_G(current_frame)->func, and can become stale by the time
a side trace compiles for that exit. Long-lived FastCGI workers with
many trace invalidation/recompile cycles match the observed failure
pattern.

Fix

Keep compile-time dispatch but resolve orig_handler against
jit->current_op_array instead of the parent's exit_info:

• On the side-trace compile path (the crash path),
  zend_jit_trace_start already sets jit->current_op_array to
  trace_buffer->op_array, which is freshly captured for the current
  compilation and doesn't depend on the parent's stale pointer.
• On the zend_jit_trace_exit_to_vm path, zend_jit_deoptimizer_start
  leaves current_op_array unset, so it is now set from
  exit_info->op_array there.

This drops the op_array parameter added to zend_jit_escape_if_undef
in #21368.

Verification

gh21267.phpt and gh21267_blacklist.phpt both pass. The original
infinite-loop fix is preserved.

Reproducer

I couldn't build a native Linux reproducer for the stale-pointer
scenario through synthetic stress. @vibbow can reproduce reliably on
IIS+FastCGI and will validate the fix once a Windows build is
available.

[dstogov]

It would be great to understand where the failure comes from.
If we somehow have an inconsistent exit_info->op_array we may get troubles in other places.

As I see, JIT_G(current_frame) is always set during trace compilation (it can't be NULL) , so this part of deduction can not be the reason of the failure.

The fix generates more expensive JIT code that performs run-time resolution, I believe it should be possible to make this resolution at compile time.

[vibbow]

I can reproduce this bug consistently. If somone can help compile a Windows version, I can test this fix

[iliaal]

1. JIT_G(current_frame) is allocated at zend_jit_trace.c:1428 before any
   exit-point creation, so the NULL hypothesis in my PR description was
   wrong. Updated the description.

2. The crash fits a stale exit_info->op_array, not a NULL one: rax+0xD0
   on an unmapped page, long-lived IIS+FastCGI worker. If this pointer
   can go stale, it's a broader invariant concern (zend_jit_dump_exit_info
   is the only other direct consumer today). I haven't yet pinned down
   the concrete path by which op_array is freed while traces referencing
   it survive.

3. Reworked the fix to keep compile-time dispatch:

   • zend_jit_escape_if_undef now uses jit->current_op_array for the
     ZEND_FUNC_INFO lookup (back to your original approach).
   • On the side-trace compile path (the actual crash path),
     zend_jit_trace_start sets jit->current_op_array to
     trace_buffer->op_array, which is freshly captured for this
     compilation and doesn't rely on the parent's possibly stale
     exit_info.
   • On the zend_jit_trace_exit_to_vm path, zend_jit_deoptimizer_start
     leaves current_op_array unset, so I set it from exit_info->op_array
     before the deopt call.

PR updated.

[dstogov]

Are you sure jit->current_op_array is always initialized?
It seems, it may be NULL on the following patch - zend_jit_trace_exit() -> zend_jit_trace_hot_side() -> zend_jit_blacklist_trace_exit() -> zend_jit_trace_exit_to_vm() - > zend_jit_trace_deoptimization() -> zend_jit_escape_if_undef().

May be I'm wrong...

[iliaal]

exit_info.op_array is written in one place, zend_jit_trace_get_exit_point (trace.c:197), and the surrounding code at trace.c:146-164 assigns op_array and stack_size together: JIT_G(current_frame) non-NULL gives a real op_array with some stack_size; the else branch sets both op_array = NULL and stack_size = 0 in the same step.

So on your path, ctx.current_op_array == NULL only when exit_info.stack_size == 0, which means zend_jit_trace_deoptimization loops over zero entries, check2 stays at -1, and zend_jit_escape_if_undef at trace.c:3606 isn't called. The NULL never reaches ZEND_FUNC_INFO(jit->current_op_array).

Can add ZEND_ASSERT(exit_info[exit_num].op_array || exit_info[exit_num].stack_size == 0) to make it explicit.

[iluuu1994]

Should the original fix be reverted until we fully understand the issue? I don't have the time to look at the problem, and also don't have a Windows setup. Otherwise we'll miss the next release cycle (I don't feel comfortable merging this without an RC-phase).

[iliaal]

Possibly, same as you I cannot reproduce the issue due to lack of windows env, fix is made based on code analysis. Ultimately be nice to have windows build the reporter could try, maybe revert from 8.5/8.4 keep in master? And then try fully patched version for 8.4/8.5 back port after current release is out?