The bug lives in YarrGenerator::generateBackreference handling in Source/JavaScriptCore/yarr/YarrJIT.cpp, in the Unicode (16-bit / non-inlined) path for reading a pattern character during a backreference match. When the YARR JIT reads the character at the current back-reference position so it can compare it against the previously captured group, it called readCharacter(op.m_checkedOffset - term->inputPosition, character, patternIndex). readCharacter’s first argument is a negative-of-input-position style offset that is subtracted from the current index register to compute the address to read from; the correct value here is 0, because patternIndex already points at the exact position of the character being matched by the backreference.

The invariant that was violated is that the read offset passed to readCharacter for the backreference’s own character must be relative to patternIndex (i.e. zero additional displacement), not the term’s whole checkedOffset. m_checkedOffset is the number of input units that have been range-checked for the entire remaining pattern from this term onward, and inputPosition is the term’s position within that; the two are only equal when the backreference is the last term in the pattern. Whenever any term follows the backreference (e.g. a trailing literal like ‘c’), checkedOffset != inputPosition, so the stale expression produced a non-zero offset and the JIT read a pattern character from the wrong input index.

The fix replaces the expression with the constant 0, so the read is taken exactly at patternIndex. Because the erroneous offset could point outside the substring actually being matched (and, combined with surrogate-pair/Unicode width handling, outside the intended in-bounds region), the comparison used out-of-bounds or wrong string data, which both produced incorrect match results and could read process memory adjacent to the string buffer. The accompanying regression test regexp-backreference-unicode-offset.js confirms the trigger condition precisely: patterns like /(.)\1c/u (backreference plus trailing term) over surrogate-pair input, warmed up 500 times to force JIT compilation, whereas /(.)\1/u (no trailing term) already worked. This is why the fix restores the invariant: with offset 0 the backreference character is always read at its true position regardless of how many terms follow it.

The primitive is an out-of-bounds/incorrect read of string-adjacent memory in the WebContent process, matching the advisory’s ‘disclosure of process memory’. It is a relative read whose displacement is derived from the pattern’s checkedOffset, not a fully attacker-controlled pointer, so it is closer to an information-leak/oracle than a direct write; there is no evidence in the diff of memory corruption or a write primitive. A leak like this is valuable as an ASLR/heap-layout defeat that could be chained with a separate memory-corruption bug, but on its own it is confined to reading WebContent memory and does not by itself yield code execution. It is contained within the sandboxed WebContent process.