RegExpStatics::executeLazy re-runs the stored regexp against the stored input to reconstruct match details, relying on the documented invariant that “RegExpStatics are only updated on successful (matching) execution. Re-running the same expression must therefore produce a matching result.” The code asserted this with MOZ_ASSERT(status == RegExpRunStatus::Success). Because MOZ_ASSERT is removed in release builds, in shipping Firefox this check did nothing: if the lazy re-execution did not return Success (the invariant broken — e.g. a case where re-running the same source/input fails to match, so status != Success), execution fell straight through. It then proceeded to “unset lazy state” and populate the match/capture boundary fields from a run that had no valid match, so the subsequently exposed match span and capture indices derive from uninitialized/stale boundary data. Consuming those bounds to slice the subject string yields an out-of-bounds read of string memory — the “incorrect boundary conditions” the advisory names.

The one-line patch upgrades the check to MOZ_RELEASE_ASSERT(status == RegExpRunStatus::Success), so the invariant is now enforced in all builds: if a lazy re-execution ever fails to match, the process aborts deterministically instead of continuing with invalid capture boundaries. The diff shows the invariant and its newly added runtime enforcement; the downstream code that would have consumed the bad boundaries is below the patched line and is not shown by the diff, so the precise OOB sink is (inferred) from the comment and the advisory’s “incorrect boundary conditions” classification. The fix is a hardening-to-crash of a previously-unchecked boundary invariant rather than a repair of the match logic itself.

The code runs in the content (renderer) process and is reachable from unprivileged JavaScript through ordinary RegExp usage and the legacy static properties that trigger lazy materialization. In unpatched release builds the realized primitive is use of invalid regexp capture/match boundary indices, i.e. an out-of-bounds read of string/heap memory that can leak data back to script (information disclosure). The precondition — forcing a lazy re-execution to fail to match despite the same source and input — is not demonstrated by the diff and is (inferred); it is the hard part of weaponization. Note the patch’s effect is to convert the condition into a deterministic crash, so the fix trades a potential memory-safety read for a controlled abort rather than correcting the match path, which bounds the pre-fix impact to a read/DoS primitive as substantiated here.