The DFG/FTL JIT tracks value types with SpeculatedType bitsets and inserts speculation checks that guard type-specialized code. JSMapIterator and JSSetIterator objects were both mapped to the generic bucket SpecObjectOther rather than to distinct speculated types: speculationFromJSType returned SpecObjectOther for both iterator JSTypes, and speculateMapIteratorObject/speculateSetObject (in DFGSpeculativeJIT and FTLLowerDFGToB3) checked against SpecObjectOther. Because both iterators shared the same speculated type, the abstract interpreter and speculation checks could not distinguish a Map iterator from a Set iterator (nor from other SpecObjectOther objects): a node speculated to operate on a Map iterator would accept a Set iterator that passed the same SpecObjectOther check, so type-specialized code then accessed the wrong iterator’s internal layout – a type confusion between JSMapIterator and JSSetIterator. Operating on one iterator’s fields as if it were the other corrupts memory (advisory class UAF/crash).

The fix introduces distinct SpeculatedType bits SpecMapIteratorObject and SpecSetIteratorObject, returns them from speculationFromJSType for the respective JSTypes, and updates the speculation checks/UseKinds to use the specific type, so a Map-iterator speculation rejects a Set iterator and vice versa.

The restored invariant is that Map and Set iterators are distinct speculated types, so the JIT’s iterator type checks are precise.

A JIT type confusion between Map and Set iterators (advisory class UAF): both mapped to SpecObjectOther, so speculation checks couldn’t tell them apart and iterator-specialized code accessed the wrong layout. That is a strong memory-corruption primitive reachable from ordinary Map/Set iterator use once JIT-compiled, in the WebContent process; the observable is a crash but the class is type confusion. Rated medium.