Fix live ranges for ZEND_JMP_SET and ZEND_COALESCE - #23507
Open
Mrmaxmeier wants to merge 1 commit into
Open
Conversation
Both opcodes write their result only on the branch they take. zend_calc_live_ranges()
started their live range right behind the definition, so it also covered the
fall-through path, on which the temporary was never written.
Normally another opcode redefines the result on the fall-through path, which
hides the problem because the backward walk stops at that later definition. Once
the optimizer has removed it the bogus range shows up:
try {
$a ?: match (true) { 1 => 1 };
} catch (UnhandledMatchError $e) {
}
Here the QM_ASSIGN of the else branch is gone because the match always throws,
and unwinding the UnhandledMatchError makes cleanup_live_vars() destroy
uninitialized stack memory. With ZEND_COALESCE the temporary slot may be shared
with a preceding opcode whose value has already been freed, which turns this
into a use after free.
Start the live range at the jump target instead. On the branch that is taken
control transfers there directly, so that is exactly the region in which the
result is defined.
Assisted-By: Claude Opus 5 <noreply@anthropic.com>
Mrmaxmeier
force-pushed
the
fix-live-range-jmp-set-coalesce
branch
from
August 29, 2026 14:47
03903ca to
a57e2fd
Compare
NickSdot
reviewed
Aug 29, 2026
Comment on lines
+19
to
+30
| } catch (UnhandledMatchError $e) { | ||
| echo $e->getMessage(), "\n"; | ||
| } | ||
|
|
||
| function coalesce($a, $b) { | ||
| return $a ?? $b; | ||
| } | ||
| var_dump(coalesce("x", "y"), coalesce(null, "y")); | ||
| echo "OK\n"; | ||
| ?> | ||
| --EXPECT-- | ||
| Unhandled match case true |
Contributor
There was a problem hiding this comment.
Suggested change
| } catch (UnhandledMatchError $e) { | |
| echo $e->getMessage(), "\n"; | |
| } | |
| function coalesce($a, $b) { | |
| return $a ?? $b; | |
| } | |
| var_dump(coalesce("x", "y"), coalesce(null, "y")); | |
| echo "OK\n"; | |
| ?> | |
| --EXPECT-- | |
| Unhandled match case true | |
| } catch (Throwable $e) { | |
| echo $e::class, ': ', $e->getMessage(), "\n"; | |
| } | |
| function coalesce($a, $b) { | |
| return $a ?? $b; | |
| } | |
| var_dump(coalesce("x", "y"), coalesce(null, "y")); | |
| echo "OK\n"; | |
| ?> | |
| --EXPECT-- | |
| UnhandledMatchError: Unhandled match case true |
Ref: https://github.com/php/php-src/blob/master/CODING_STANDARDS.md#testing
Comment on lines
+16
to
+28
| } catch (UnhandledMatchError $e) { | ||
| echo $e->getMessage(), "\n"; | ||
| } | ||
|
|
||
| function elvis($a, $b) { | ||
| return $a ?: $b; | ||
| } | ||
| var_dump(elvis("x", "y"), elvis("", "y"), elvis(null, "z")); | ||
| echo "OK\n"; | ||
| ?> | ||
| --EXPECTF-- | ||
| Warning: Undefined variable $a in %s on line %d | ||
| Unhandled match case true |
Contributor
There was a problem hiding this comment.
Suggested change
| } catch (UnhandledMatchError $e) { | |
| echo $e->getMessage(), "\n"; | |
| } | |
| function elvis($a, $b) { | |
| return $a ?: $b; | |
| } | |
| var_dump(elvis("x", "y"), elvis("", "y"), elvis(null, "z")); | |
| echo "OK\n"; | |
| ?> | |
| --EXPECTF-- | |
| Warning: Undefined variable $a in %s on line %d | |
| Unhandled match case true | |
| } catch (Throwable $e) { | |
| echo $e::class, ': ', $e->getMessage(), "\n"; | |
| } | |
| function elvis($a, $b) { | |
| return $a ?: $b; | |
| } | |
| var_dump(elvis("x", "y"), elvis("", "y"), elvis(null, "z")); | |
| echo "OK\n"; | |
| ?> | |
| --EXPECTF-- | |
| Warning: Undefined variable $a in %s on line %d | |
| UnhandledMatchError: Unhandled match case true |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Hi,
we ran into a use of an uninitialized value bug in the
fuzzer-function-jitfuzzing target:and the
??variant:Note: MSAN would be the right tool to detect this bug, but oss-fuzz flags this harness as ASAN-only because the JIT doesn't work with MSAN.
ASAN backtrace for reproducer (
?:/ ZEND_JMP_SET)ASAN backtrace for the
??/ ZEND_COALESCE variantZEND_JMP_SET(?:) andZEND_COALESCE(??) both write their result only on the branch they take.zend_calc_live_ranges()started their live range right behind the definition, so the range also covered the fall-through path, on which the temporary was never written at all.Normally this is harmless because another opcode redefines the result on the fall-through path, and the backward walk stops at that later definition, hiding the bogus range. Once the optimizer removes that redefinition the range shows up. In the reproducer the
QM_ASSIGNof the else branch is gone because thematchalways throws, so unwinding theUnhandledMatchErrormakescleanup_live_vars()destroy uninitialized stack memory.The fix starts the live range at the jump target instead of behind the definition. On the branch that is taken control transfers there directly, so that is exactly the region in which the result is defined. If the result is freed right at the jump target the range is empty and no range is emitted at all.
Thanks!
Found by the CISPA Fandango team while triaging findings in oss-fuzz harnesses.