Repository navigation
1.14.0: chain D, measured — the stale-store claim does not hold - #7
Merged
Merged
Conversation
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
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.
A negative result, published because a matrix that only lists successes is not a matrix.
One of the chains circulating for these CVEs says the request shutdown reads a stale
EG(objects_store)left by a request that died mid-startup, and the next request on the same worker consumes it. We measured that step and it does not behave that way.What was measured.
php:8.4.26-apache, mod_php, one worker, breakpoint atphp_request_shutdown(main/main.c:1891), three requests on that worker: a warmup GET (200), a chunked 70 MB body that dies at startup (500), a GET after the OOM (200). At the breakpoint, all three are identical: same store pointer,top=1,size=1024,flh=-1,current_execute_datanil, samevm_stackbounds. No crash, and the worker kept serving.Where it stops, which is the important part. We measured the store header and its first bucket entries, not the whole 1024-entry array, and all three observations were made with the store empty at shutdown. A request that reaches shutdown holding live objects is another state, and this says nothing about it.
What survives. The bucket-array variant: segfo confirms the
object_bucketsuse-after-free with a crash and marks RCE unproven; cookie-bakery publishes a full chain throughzend_objects_store_deland afree_objpivot, with ASLR off. A working ASLR-off chain and an identical-header result are not in conflict — they are about different memory. The patch that resetsobject_bucketsis consistent with that variant, not with a stale header.Changed in our own matrix. The Chain D row goes from
UNSUPPORTEDto something narrower: unsupported as a stale-store claim, with the bucket variant explicitly open.Both languages, plus the transcript in
raw/chain-d-eg-shutdown.txt.