The bug is in RenderTreeBuilder::Ruby::findOrCreateParentForStyleBasedRubyChild in Source/WebCore/rendering/updating/RenderTreeBuilderRuby.cpp, which, when appending a child under a RubyBlock parent, tries to locate the existing anonymous ruby box that should wrap ruby children. The pre-fix code did ‘if (parent.style().display() == DisplayType::RubyBlock && parent.firstChild())’ and then ASSERTed that ‘parent.firstChild()->style().display() == DisplayType::Ruby’ before returning parent.firstChild() downcast to RenderElement. The violated invariant is that the RubyBlock’s immediate first child is always the anonymous Ruby-display box. That assumption is false in the presence of render-tree continuations: when inline content (the ruby base) contains a block-level box (the <div> inside the <span> inside <rb> in the test), the inline is split and continuations are inserted, so the RubyBlock’s first child may be some other anonymous wrapper rather than the expected Ruby box. In a release build the ASSERT is compiled out, so the code would unconditionally downcast and return a first child that is not the anonymous ruby box, wiring subsequent children into the wrong renderer and corrupting the render tree (leading to the crash the test guards against); in a debug build the ASSERT fires.

The fix replaces the single-firstChild check with a descent loop: for (CheckedPtr first = parent.firstChild(); first; first = first->firstChildSlow()) it walks down the first-child chain, bailing with ASSERT_NOT_REACHED if it ever encounters a non-anonymous box, and returns the first box whose display is Ruby. This restores the invariant by actually searching for the anonymous ruby box through the continuation-introduced wrapper layers instead of assuming it is the immediate first child, and the accompanying FIXME explicitly notes ‘It should be the immediate child but continuations can break this assumption.’ The regression test (<ruby style=‘position: absolute’> with an <rb><span>…<div>forced</div>…</span></rb>) reproduces exactly the continuation-splitting scenario and passes if it does not crash.

The established primitive is render-tree corruption leading to an unexpected process crash in the sandboxed WebContent process, matching the CVE’s stated impact and medium severity. The pre-fix code returned/operated on a renderer of an unexpected type (an incorrect downcast target), which is a type-confusion-flavored logic error; whether it yields anything beyond a controlled crash (e.g. a limited type confusion usable toward memory corruption) is not demonstrated by the diff and would depend on how the misparented renderer is later used. Realistically this reads as a reliability/DoS bug reachable purely from crafted HTML/CSS with no user interaction; escalation to code execution would require additional primitives not shown here. It is confined to WebContent and does not by itself cross the sandbox.