The patch fixes a stale-flush bug in DFG/FTL OSR-availability analysis that governs how sunken (materialized) objects are reconstructed on OSR exit. AvailabilityMap tracks, for each bytecode local and for each PromotedHeapLocation of a phantom/sunken object, an Availability that may carry a FlushedAt location — a virtual register (stack slot) where the value has been spilled. On OSR exit the FTL recovers a materialization’s field either from its SSA node or, if the field is ‘flush useful’, from that stack slot. The violated invariant is that a heap availability’s FlushedAt stack slot must still hold the expected DFG node’s value at the exit point. LocalOSRAvailabilityCalculator::executeNode processed GetStack/PutStack/KillStack by updating only the m_locals flush state; it never invalidated heap availabilities that pointed at a stack slot which a later PutStack or KillStack reused for a different value. Consequently a sunken object’s promoted-location Availability could keep a FlushedAt pointing at a virtual register whose contents had since been clobbered, so on OSR exit the materialization would read a wrong/attacker-influenced value out of that slot.

The fix adds a killHeaps lambda invoked when executeNode sees a PutStack (for its target operand) or KillStack: it scans m_availability.m_heap and, for every heap entry whose FlushedAt virtualRegister equals the clobbered operand’s register, resets it to FlushedAt(ConflictingFlush), forcing the OSR exit to rematerialize from the SSA node instead of the stale slot. The heap/local pruning was also refactored from the mutating pruneHeap()+pruneByLiveness() into a non-mutating filterByLiveness() that first filters locals by bytecode liveness and then rebuilds the heap from nodes reachable from the surviving locals, and a debug-only validateAvailability() was added (gated on Options::validateFTLOSRExitLiveness) that cross-checks each ‘flush useful’ heap entry against the local occupying the same stack slot and DFG_CRASHes if they disagree on the node or flush format. New ASSERT(!isDead()) checks on inline-call-frame argumentCount/callee/argument availabilities, and an ASSERT(property.value().kind() != ExitValueDead) in the OSR exit stub compiler, assert the corrected invariant at materialization time.

The added regression test osr-availability-heap-materialization-clobbered.js drives phantom arguments objects (arg()/arg.apply()) inside a loop with a throwing call so the sunken arguments materialization’s flushed slot is reused, reproducing the disagreement.

The primitive is a wrong-value / type-confusion at OSR-exit object materialization: a sunken object’s field is reconstructed from a clobbered stack slot, so an attacker who grooms which value occupies the reused slot can place an unexpected/type-inconsistent value into a JS object. In JSC such deopt-time confusions are routinely escalated to addrof/fakeobj and then to arbitrary read/write and code execution, so realistic escalation is toward RCE rather than a mere controlled crash. The bug is in JavaScriptCore and is confined to the WebContent process, subject to the WebKit sandbox; exploitation still requires a separate sandbox escape for full device compromise. Reachability is high (pure JS, no special API), matching the ‘maliciously crafted web content -> memory corruption’ description.