jit::ExtractLinearSum recurses through add/sub nodes to pull out a linear sum, and it carries a MathSpace space parameter telling it whether the arithmetic is idealized (Infinite) or wrapping (Modulo). After an early MOZ_ASSERT(space == MathSpace::Modulo || space == MathSpace::Infinite), the old code proceeded to decompose the operands lhs = ins->getOperand(0) / rhs = ins->getOperand(1) identically regardless of space, extracting constant offsets from MAdd/MSub as if the arithmetic never wrapped. That is unsound in Modulo space: when the operation is defined to wrap at the int32 boundary, the extracted term + constant relationship does not actually hold for inputs near the wrap point, so a consumer that trusts the linear sum (e.g. to conclude an index is within a length and drop the bounds check) can be fed a wrong offset. The advisory describes the observable effect precisely: an out-of-bounds read/write “by confusing array index sizes.”

The patch adds, immediately after that assertion, a hard short-circuit: if (space == MathSpace::Modulo) { return SimpleLinearSum(ins, 0); }. In modulo space the function now refuses to decompose the expression and instead returns the opaque sum (the whole node as term, constant 0), so no false constant offset is ever derived from wrapping arithmetic. Only in Infinite space does it continue into the operand-splitting logic. This restores the invariant that an extracted non-zero constant offset is only ever produced when the arithmetic is genuinely non-wrapping, preventing the downstream optimization from eliminating a bounds check it cannot actually justify. The advisory’s OOB classification matches the diff: the root is an unsound JIT analysis (a logic error in ExtractLinearSum’s handling of modulo arithmetic) whose exploitable consequence is an out-of-bounds memory access from miscomputed index bounds; I keep OOB as the class since that is the memory-safety sink the fix protects.

This is a renderer-process JIT correctness bug in IonMonkey, reachable from unprivileged web content; the CVSS vector AV:N/AC:L/PR:N/UI:R (8.8) indicates it needs the victim to load attacker JavaScript but no further privilege. The primitive is an out-of-bounds read and write arising from an eliminated bounds check under wrapping arithmetic — a strong, attacker-steerable memory-corruption primitive (this was a Pwn2Own entry by Manfred Paul via ZDI). The diff substantiates the unsound-analysis root and the bounds-check-elimination surface; converting the OOB into full code execution requires the usual renderer exploitation steps, which the diff does not show. Gating: the attacker must get the code JIT-compiled (hot path) and shape the index arithmetic so Ion treats it as modulo-space, which is achievable from pure JS.