Project Fortify, an experimental security project, has identified the following potential security issue. If you’re a feature owner CC-ed on this bug, please do your best to review these reports. Please see https://chromium.googlesource.com/chromium/src/+/main/docs/security/ai-generated-security-bugs-faq.md for more information.

Overview: Document::IsInSlotAssignmentRecalc() tests strict equality against 1 rather than checking for a depth of at least 1, causing it to return false when the recalc depth is 2 or greater. When release builds encounter nested recalculations, Node::AssignedSlot() fails open and re-enters RecalcAssignment(). This can allow nested recalculations to clear and prompt-free the backing buffer of HTMLSlotElement::assigned_nodes_ while an outer frame is iterating over it by reference, potentially resulting in a use-after-free.

Affected files:

• third_party/blink/renderer/core/dom/document.h
• third_party/blink/renderer/core/dom/node.cc
• third_party/blink/renderer/core/dom/flat_tree_traversal.cc
• third_party/blink/renderer/core/dom/slot_assignment.cc
• third_party/blink/renderer/core/html/html_slot_element.cc

Estimated timestamp from git blame: 2018-12-03

Root Cause Analysis

In third_party/blink/renderer/core/dom/document.h (lines 1992-1997), Document::IsInSlotAssignmentRecalc() is defined as:

bool IsInSlotAssignmentRecalc() const {
  // Since we forbid recursive slot assignement recalc, the depth should be <= 1.
  DCHECK_LE(slot_assignment_recalc_depth_, 1u);
  return slot_assignment_recalc_depth_ == 1;
}

The predicate checks slot_assignment_recalc_depth_ == 1 rather than >= 1 (contrast with IsFlatTreeTraversalForbidden() at lines 1985-1987, which checks > 0). The recursion depth counter (Document::slot_assignment_recalc_depth_, line 3140) is unconditionally compiled and incremented whenever SlotAssignment::RecalcAssignment() runs (third_party/blink/renderer/core/dom/slot_assignment.cc:236-237). However, recursion-blocking scopes such as SlotAssignmentRecalcForbiddenScope (third_party/blink/renderer/core/dom/slot_assignment_recalc_forbidden_scope.h:32-43) and the anti-recursion checks in SlotAssignment::RecalcAssignment() (slot_assignment.cc:239-241) are no-ops or DCHECK-only in release builds.

Mechanism of the Failure

When a nested slot assignment recalculation reaches depth 2 (for instance, via FlatTreeTraversal::TraverseParent’s fallback-slot branch at flat_tree_traversal.cc:180, which calls HTMLSlotElement::AssignedNodes() without a depth check), Document::IsInSlotAssignmentRecalc() evaluates to false because 2 == 1 is false.

This causes Node::AssignedSlot() (third_party/blink/renderer/core/dom/node.cc:3546-3553) to fail open:

if (GetDocument().IsInSlotAssignmentRecalc()) {
  // FlatTreeNodeData is not reliable here. Entering slow path.
  return root->AssignedSlotFor(*this);
}
root->GetSlotAssignment().RecalcAssignment(); // Reaches here at depth >= 2

If a shadow root is re-dirtied during nested recalculation (e.g. cross-tree reassignment triggered from HTMLDetailsElement::ManuallyAssignSlots / HTMLSlotElement::Assign), RecalcAssignment() does not early-return and enters depth 3. The re-entrant recalculation calls HTMLSlotElement::WillRecalcAssignedNodes() -> ClearAssignedNodes() (third_party/blink/renderer/core/html/html_slot_element.cc:294-296), which calls assigned_nodes_.clear().

In wtf/vector.h:1688-1691, Vector::clear() executes ShrinkCapacity(0), which triggers an immediate prompt-free of the HeapVectorBacking<Member<Node>> in Oilpan via cppgc::subtle::FreeUnreferencedObject (third_party/blink/renderer/platform/heap/collection_support/heap_vector_backing.h:58-60). Because HTMLSlotElement::DetachDisplayLockedAssignedNodesLayoutTreeIfNeeded() (html_slot_element.cc:352-359) and UpdateFlatTreeNodeDataForAssignedNodes() (:305-336) iterate over assigned_nodes_ by direct reference without a defensive copy, returning to the outer frame resumes iteration over freed memory.

Potential Trigger Steps

(Note: These are potential steps deduced from static analysis; our tooling agent does not have the ability to run dynamic code.)

1. Environment Setup: Execute in a context where an active AXObjectCacheImpl is maintained (such as on macOS or Android where AriaModalPrunesAXTree is enabled, or with accessibility active).
2. DOM Configuration:
   • Construct host element H1 with author shadow root R1 containing an assigned slot in a display-locked subtree (content-visibility: hidden).
   • Attach a <details> element D (having UA shadow root R2) under H1.
   • Assign a light child X of D to an R1 slot using r1slot.assign(X).
   • Set up an aria-modal="true" dialog and focus such that accessibility removal triggers an AncestorAriaModalDialog walk across the fallback slot in R2 and the D -> H1 host-child boundary.
3. Lifecycle Trigger: Initiate slot assignment resolution (e.g., during layout/style update):
   • Depth 1: R1.RecalcAssignment() starts. In DetachDisplayLockedAssignedNodesLayoutTreeIfNeeded(), current->DetachLayoutTree() triggers AX removal.
   • Depth 2: The AX walk calls parent_slot->AssignedNodes(), starting R2.RecalcAssignment(). Inside R2, HTMLDetailsElement::ManuallyAssignSlots() reassigns X, calling DidSlotChange() on R1’s slot and marking R1 dirty again.
   • Depth 3: AX removal in R2 traverses the host-child boundary to D.AssignedSlot(). At depth 2, IsInSlotAssignmentRecalc() returns false, invoking R1.RecalcAssignment() re-entrantly.
   • UAF: Depth 3 prompt-frees R1’s assigned_nodes_ backing buffer. When the stack unwinds to depth 1, the range-for loop in DetachDisplayLockedAssignedNodesLayoutTreeIfNeeded() dereferences freed memory.

Impact

Use-after-free in the sandboxed Blink renderer process on a prompt-freed HeapVectorBacking<Member<Node>>. MiraclePtr does not protect Oilpan heap vectors. This presents a potential remote code execution (RCE) primitive in the renderer process.

Suggested Fix

1. Correct the predicate in third_party/blink/renderer/core/dom/document.h to check for depth >= 1:

   bool IsInSlotAssignmentRecalc() const {
     DCHECK_LE(slot_assignment_recalc_depth_, 1u);
     return slot_assignment_recalc_depth_ >= 1;
   }
   

2. As defense-in-depth, take defensive copies before iterating over assigned_nodes_ in HTMLSlotElement::DetachDisplayLockedAssignedNodesLayoutTreeIfNeeded() and HTMLSlotElement::UpdateFlatTreeNodeDataForAssignedNodes(), matching the existing defensive copies in AttachLayoutTreeForSlotChildren(), DetachLayoutTree(), RebuildDistributedChildrenLayoutTrees(), and RecalcStyleForSlotChildren() (html_slot_element.cc:408, 418, 444, 555).

Evaluated with Chrome root at commit: c6718ebbf2c677c6f63691e28c7801c563f6b19c

Results so far have been promising, but there can be wrong deductions. Feel free to adjust as follows:

• If you are familiar with the severity guidelines, you may adjust the severity.
• If this is a false positive, and there’s no work to be done, please close as WAI.
• If there is work to do here but not a vulnerability, please change the issue type to Task/Bug/FR.

Data from false positives will be used to improve accuracy over time. And please feel free to reach out to me directly if you have concerns or feedback on the project.