Report description

[Security][Viz] Re-entrancy desync in Surface::UpdateActivationDependencies leaves a stale SurfaceAllocationGroup pointer — heap-use-after-free in the GPU process

Bug location

Where do you want to report your vulnerability?

Chrome VRP – Report security issues affecting the Chrome browser. See program rules

The problem

Please describe the technical details of the vulnerability

Summary

Surface::UpdateActivationDependencies() (surface.cc:781-853) publishes this into SurfaceAllocationGroup::blocked_embedders_ before it commits its own bookkeeping members, and the publication call group->UpdateLastPendingReferenceAndMaybeActivate() is re-entrant. During that window the surface’s activation_dependencies_ and blocking_allocation_groups_ are empty, so a re-entrant Surface::OnActivationDependencyResolved() performs two erase() calls that are silent no-ops while the allocation group has already removed the surface from blocked_embedders_.

The result is a permanent desync: the surface holds a pointer to the allocation group, and the allocation group has no record of the surface. The group then satisfies IsReadyToDestroy() and is deleted by SurfaceManager’s garbage collector while the surface still holds and dereferences the pointer, producing a heap-use-after-free in the GPU process on the VizCompositorTh thread.

The desync is normally fatal-but-harmless because the re-entrant path dies on CHECK(pending_frame_data_) (surface.cc:500). Commit 917ae5350f9fc "[viz] Add view transition dependency for Surface activation" added || !view_transition_dependencies_.empty() to the early return at surface.cc:445-448; a kAnimateRenderer transition directive with an unknown token populates that set at CommitFrame:319-336, i.e. before UpdateActivationDependencies runs, so the CHECK is skipped and the desync survives silently.

This is the same bug class as the two July 2026 re-entrancy fixes in this file (4c246406e3da5, bug 514442821 — RecomputeActiveReferencedSurfaces; d798f3bad2546, bug 534858939 — CommitFramesRecursively), in a third function that neither fix touched. UpdateActivationDependencies does not appear in either diff.

Affected version

Vulnerability class

Re-entrancy / state desync → dangling pointer → Heap Use-After-Free (CWE-416)

Component

Internals>Compositing>Viz — components/viz/service/surfaces/surface.cc, components/viz/service/surfaces/surface_allocation_group.cc

Attacker model

Compromised renderer process. The renderer controls the CompositorFrame fields that drive this code: metadata.activation_dependencies, metadata.referenced_surfaces, metadata.deadline, metadata.transition_directives and the LocalSurfaceId (including embed_token), all submitted over viz.mojom.CompositorFrameSink::SubmitCompositorFrame. Per the Chrome VRP rules (docs/security/vrp-faq.md:73-80 — “Instead of providing a patch, use MojoJS to simulate a compromised renderer”), the attached PoC uses MojoJS rather than a patch.

The PoC obtains its frame sinks exclusively through blink.mojom.EmbeddedFrameSinkProvider, the process-scoped interface an ordinary renderer already possesses (content/browser/renderer_host/render_process_host_impl_receiver_bindings.cc:173-176). No privileged viz interface (services/viz/privileged/**, FrameSinkManager, GpuService, DisplayPrivate, VizMain) is used, and the browser-side FrameSinkId gate (client_id must equal the renderer’s ChildProcessId, sink_id must be > INT32_MAX) is respected.

Security boundary

Renderer → GPU process. Viz is the display compositor and runs in the GPU process; the crashing thread is VizCompositorTh and the report is emitted by the GPU process (see evidence). The GPU process is sandboxed on desktop platforms and unsandboxed on Android (docs/security/process-sandboxes-by-platform.md).

The missing invariant is that a Surface and a SurfaceAllocationGroup must agree on whether the surface is a blocked embedder of that group. Nothing enforces it: SurfaceAllocationGroup::UnregisterBlockedEmbedder() guards the relationship with DCHECK(blocked_embedders_.count(surface)), which is compiled out in release.

Root cause

Intended invariant. Surface::blocking_allocation_groups_ and SurfaceAllocationGroup::blocked_embedders_ are two halves of the same relation and must be updated atomically with respect to re-entrancy.

Actual behaviour. Surface::UpdateActivationDependencies() tears the relation down, publishes one half, runs re-entrant code, and only then commits the other half:

// components/viz/service/surfaces/surface.cc:781-853
void Surface::UpdateActivationDependencies(const CompositorFrame& current_frame) {
  // (1) tear down and CLEAR both members
  for (SurfaceAllocationGroup* group : blocking_allocation_groups_)
    group->UnregisterBlockedEmbedder(this, false /* did_activate */);
  blocking_allocation_groups_.clear();
  activation_dependencies_.clear();
  ...
  for (const SurfaceId& surface_id : current_frame.metadata.activation_dependencies) {
    SurfaceAllocationGroup* group =
        surface_manager_->GetOrCreateAllocationGroupForSurfaceId(surface_id);
    ...
    if (group)
      group->UpdateLastPendingReferenceAndMaybeActivate(surface_id);   // (2) RE-ENTRANT
    ...
    if (group) {
      group->RegisterBlockedEmbedder(this, surface_id);                // (3) publishes `this`
      new_blocking_allocation_groups.insert(group);
    }
    new_activation_dependencies.push_back(surface_id);
  }
  // (4) members committed only here
  activation_dependencies_    = std::move(new_activation_dependencies);
  blocking_allocation_groups_ = std::move(new_blocking_allocation_groups);
}

From the second loop iteration onwards, this is registered inside the groups of iterations 0..k-1 (step 3) while its own members are still empty (step 1) and not yet committed (step 4).

Why the existing checks do not help. The re-entrant call at step 2 can reach back into the same surface:

// components/viz/service/surfaces/surface.cc:439-455
void Surface::OnActivationDependencyResolved(const SurfaceId& activation_dependency,
                                             SurfaceAllocationGroup* group) {
  DCHECK(activation_dependencies_.count(activation_dependency));   // compiled out
  activation_dependencies_.erase(activation_dependency);           // NO-OP: cleared at :788
  blocking_allocation_groups_.erase(group);                        // NO-OP: cleared at :787
  if (!activation_dependencies_.empty() ||
      !view_transition_dependencies_.empty()) {                    // <- added by 917ae5350f9fc
    return;                                                        //    skips the CHECK below
  }
  ...
  ActivatePendingFrame();          // would CHECK(pending_frame_data_) at :500 and abort
}

Meanwhile the group has already erased the surface before dispatching (surface_allocation_group.cc:173-176, erase-then-notify). Step 4 then commits new_blocking_allocation_groups, which still contains that group.

Net state: surface → group, group ↛ surface.

Because the group no longer lists the surface as a blocked embedder, it satisfies SurfaceAllocationGroup::IsReadyToDestroy() (surface_allocation_group.cc:31-33) and is destroyed by SurfaceManager::MaybeGarbageCollectAllocationGroups(). And because the surface’s destructor only unregisters from groups listed in its own set, the relation is never repaired:

// components/viz/service/surfaces/surface.cc:150-156  (~Surface)
for (SurfaceAllocationGroup* group : blocking_allocation_groups_)
  group->UnregisterBlockedEmbedder(this, false /* did_activate */);

Source-to-sink trace

1. Compromised renderer submits a CompositorFrame for surface S whose metadata.activation_dependencies name surfaces in two distinct allocation groups, whose metadata.deadline is non-zero (so the frame stays pending), and whose metadata.transition_directives contain a kAnimateRenderer directive with an unknown token, populating view_transition_dependencies_ at CommitFrame:319-336.
2. Surface::CommitFrame → Surface::UpdateActivationDependencies (surface.cc:781).
3. :783-788 unregisters S from all groups and clears blocking_allocation_groups_ / activation_dependencies_.
4. Loop iteration 1 registers S into group G (:841 RegisterBlockedEmbedder).
5. Loop iteration 2 calls the re-entrant :813 group->UpdateLastPendingReferenceAndMaybeActivate(surface_id) → SurfaceAllocationGroup::SetIsFallbackAndMaybeActivate → child activation → Surface::ActivateFrame → RecomputeActiveReferencedSurfaces → SurfaceAllocationGroup::UpdateLastActiveReferenceAndMaybeActivate → a second child activation → SurfaceAllocationGroup::OnFirstSurfaceActivation (surface_allocation_group.cc:173-176) → back into S: Surface::OnActivationDependencyResolved.
6. In S, both erase() calls at :443-444 are no-ops (the sets were cleared at step 3); the early return at :445-448 is taken because view_transition_dependencies_ is non-empty, so the otherwise-fatal CHECK(pending_frame_data_) at :500 is skipped. G has already erased S from blocked_embedders_.
7. :852-853 commits new_blocking_allocation_groups, which still contains G. Desync established.
8. G becomes ready to destroy and is freed by SurfaceManager::ExpireOldTemporaryReferences → GarbageCollectSurfaces → MaybeGarbageCollectAllocationGroups (a base::RepeatingTimer).
9. A later BeginFrame activates S: CompositorFrameSinkSupport::OnBeginFrame → CheckPendingSurfaces → Surface::ActivateIfDeadlinePassed → ActivatePendingFrame → Surface::ActivateFrame, whose loop at surface.cc:698-699 dereferences the freed G:

   for (SurfaceAllocationGroup* group : blocking_allocation_groups_)
     group->UnregisterBlockedEmbedder(this, true /* did_activate */);
   blocking_allocation_groups_.clear();
   

Sink-to-source trace

• Sink: read of the freed SurfaceAllocationGroup inside SurfaceAllocationGroup::UnregisterBlockedEmbedder() (the blocked_embedders_ flat_map’s vector members, 48 bytes into the 168-byte object).
• Holder: base::flat_set<raw_ptr<SurfaceAllocationGroup, CtnExperimental>> blocking_allocation_groups_ (surface.h:442).
• Freer: SurfaceManager::MaybeGarbageCollectAllocationGroups(), reached from the ExpireOldTemporaryReferences repeating timer.
• No guard: the relation is asserted only by DCHECK(blocked_embedders_.count(surface)), compiled out in release; there is no re-entrancy flag, no copy-before-publish, and no post-condition check.
• Source: renderer-controlled CompositorFrame metadata over viz.mojom.CompositorFrameSink::SubmitCompositorFrame.

Reproduction steps

No Chromium build is required — the PoC runs against the official ASan build.

1. Fetch and unpack https://commondatastorage.googleapis.com/chromium-browser-asan/linux-release/asan-linux-release-1669525.zip.
2. From the PoC directory, serve the harness and run the driver:

   python3 vizdrv.py poc_config.html --config e2_stale_group_uaf_45s.json --seconds 90
   

   The driver starts a loopback HTTP server, launches the ASan Chrome with

   --headless=new --no-sandbox --enable-blink-features=MojoJS,MojoJSTest
   --no-zygote --gpu-launcher='env ASAN_OPTIONS=…:handle_abort=1:allow_user_segv_handler=0…'
   

   and captures the GPU process’s ASan output.
3. The GPU process aborts with AddressSanitizer: heap-use-after-free in viz::SurfaceAllocationGroup::UnregisterBlockedEmbedder.

The page creates several CompositorFrameSinks through blink.mojom.EmbeddedFrameSinkProvider and submits CompositorFrames whose activation dependencies, referenced surfaces and transition directives establish the desync described above; the free is then performed by viz’s own garbage-collection timer, and the use by the next BeginFrame.

Flags. --no-sandbox is a requirement of the ASan build, not of the bug. --enable-blink-features=MojoJS,MojoJSTest is the sanctioned compromised-renderer simulation. --disable-gpu is not required — verified by re-running without it. No feature flags, no --enable-features, no origin trial.

PoC attachments

Actual result

AddressSanitizer: heap-use-after-free, READ of size 8, in the GPU process on VizCompositorTh, when Surface::ActivateFrame iterates blocking_allocation_groups_ and calls into an allocation group that the surface’s own registration was silently dropped from.

Expected result

Surface::blocking_allocation_groups_ and SurfaceAllocationGroup::blocked_embedders_ remain consistent across re-entrancy, or the surface never retains a group it is not registered with.

Crash / ASan evidence

==739740==ERROR: AddressSanitizer: heap-use-after-free on address 0x7c1d674aad20
READ of size 8 at 0x7c1d674aad20 thread T27 (VizCompositorTh)
    #0 viz::SurfaceAllocationGroup::UnregisterBlockedEmbedder(viz::Surface*, bool)
         third_party/libc++/src/include/__vector/vector.h:351:57
    #1 viz::Surface::ActivateFrame(viz::Surface::FrameData)   components/viz/service/surfaces/surface.cc:699:12
    #2 viz::Surface::ActivatePendingFrame()                   surface.cc:514:3
    #3 viz::Surface::ActivatePendingFrameForDeadline()        surface.cc:472:3
    #4 viz::Surface::ActivateIfDeadlinePassed()               surface.cc:249:3
    #5 viz::CompositorFrameSinkSupport::CheckPendingSurfaces()
         components/viz/service/frame_sinks/compositor_frame_sink_support.cc:1572:14
    #6 viz::CompositorFrameSinkSupport::OnBeginFrame(viz::BeginFrameArgs const&)
         compositor_frame_sink_support.cc:1152:3
    #7 viz::DelayBasedBeginFrameSource::IssueBeginFrameToObserver(...)
         components/viz/common/frame_sinks/begin_frame_source.cc:50:13

0x7c1d674aad20 is located 48 bytes inside of 168-byte region [0x7c1d674aacf0,0x7c1d674aad98)

freed by thread T27 (VizCompositorTh) here:
    #1 viz::SurfaceManager::MaybeGarbageCollectAllocationGroups()
    #2 viz::SurfaceManager::GarbageCollectSurfaces()      components/viz/service/surfaces/surface_manager.cc:248:3
    #3 viz::SurfaceManager::ExpireOldTemporaryReferences() surface_manager.cc:493:3
    #6 base::RepeatingTimer::RunUserTask()                 base/timer/timer.cc:215:8

previously allocated by thread T27 (VizCompositorTh) here:
    #1 viz::SurfaceManager::GetOrCreateAllocationGroupForSurfaceId(viz::SurfaceId const&)
    #2 viz::SurfaceManager::CreateSurface(...)             surface_manager.cc:136:7
    #3 viz::CompositorFrameSinkSupport::MaybeSubmitCompositorFrame(...)
         compositor_frame_sink_support.cc:886:52
    #4 viz::CompositorFrameSinkImpl::SubmitCompositorFrame(...)
         components/viz/service/frame_sinks/compositor_frame_sink_impl.cc:166:33
    #5 viz::mojom::CompositorFrameSinkStubDispatch::Accept(viz::mojom::CompositorFrameSink*, mojo::Message*)
    #6 mojo::InterfaceEndpointClient::HandleValidatedMessage(mojo::Message*)

SUMMARY: AddressSanitizer: heap-use-after-free __vector/vector.h:351:57
         in viz::SurfaceAllocationGroup::UnregisterBlockedEmbedder(viz::Surface*, bool)

The 168-byte region is SurfaceAllocationGroup. The allocation stack ends in mojom::CompositorFrameSinkStubDispatch::Accept, i.e. the object is created directly by a renderer IPC; the free is performed by viz’s own GC timer; the use happens on the next BeginFrame.

Reproduction rate: 5/5 with e2_stale_group_uaf_45s.json. Independently re-run 4/4 by a second operator, including one run with --disable-gpu removed.

Controls: removing only the kAnimateRenderer transition directive changes the outcome to Check failed: pending_frame_data_ at surface.cc:500 with no ASan report — isolating the single ingredient that converts a fatal CHECK into silent memory corruption. Removing only the re-entrancy edge yields a clean run. A separate channel-proof run (chrome://crash/gpu/use-after-free) confirms ASan reporting works in that same GPU process, so a clean control is a real negative.

Impact analysis

Impact analysis

Security impact

Renderer-controlled heap use-after-free in the GPU process, which serves every renderer, so this is a cross-renderer surface. The freed object is a 168-byte SurfaceAllocationGroup; the use is a read of its blocked_embedders_ container members followed by a flat_map erase through those members.

Per docs/security/severity-guidelines.md, memory corruption in the GPU process where it is sandboxed is High (S1) (:83). The GPU process is unsandboxed on Android (docs/security/process-sandboxes-by-platform.md); the frame fields required here are produced by cc rather than by ordinary JavaScript, so this is reported as compromised-renderer reachable (S1-shaped) rather than directly web-content reachable.

MiraclePtr analysis (stated explicitly)

ASan reports:

MiraclePtr Status: MANUAL ANALYSIS REQUIRED
A pointer to the same region was extracted from a raw_ptr<T> object prior to this crash.

Performing that analysis: the dangling pointer is held in base::flat_set<raw_ptr<SurfaceAllocationGroup, CtnExperimental>> blocking_allocation_groups_ (surface.h:442), and blocking_allocation_groups_.clear() occurs after the loop that dereferences the extracted plain pointer (surface.cc:698-700), so the raw_ptr is alive across the whole extraction→use window. Under BackupRefPtr the slot would therefore stay quarantined, and severity-guidelines.md:223-236 would apply.

This is disclosed proactively rather than argued around. Two points remain relevant:

1. The same underlying defect — a torn Surface ↔ SurfaceAllocationGroup relation — also exists in the inverse direction, where the stale pointer is a plain Surface*: SurfaceAllocationGroup::blocked_embedders_ is declared base::flat_map<Surface*, SurfaceId> (surface_allocation_group.h:170) while both sibling containers in the same class (surfaces_, active_embedders_) use raw_ptr. A surface that is missing from its own blocking_allocation_groups_ is never removed from a group’s blocked_embedders_ by ~Surface (surface.cc:150-156), and the group later dereferences that plain pointer at surface_allocation_group.cc:176 and :183. MiraclePtr does not cover that pointer. (Investigation of this direction is in progress and will be supplied as a follow-up if it reproduces.)
2. Independently of exploitability, the desync is a correctness defect that today only fails safe by accident, via a CHECK that a shipped feature (917ae5350f9fc) learned to skip.

Reachability

Regression / bisection

Not a regression of the July 2026 hardening work — Surface::UpdateActivationDependencies was never covered by it. 4c246406e3da5 (bug 514442821) fixed Surface::RecomputeActiveReferencedSurfaces; d798f3bad2546 (bug 534858939) fixed Surface::CommitFramesRecursively and SurfaceManager. The string UpdateActivationDependencies appears zero times in both diffs.

The silent-failure mode was introduced by 917ae5350f9fc "[viz] Add view transition dependency for Surface activation" (2025-09-22), which added the view_transition_dependencies_ clause to the early return at surface.cc:445-448; before it, the same desync terminated at CHECK(pending_frame_data_).

Suggested fix

Attached as viz-uaf-surfaceallocationgroup-fix.patch (applies cleanly to 9d4f657b, verified with git apply --check).

The minimal change is to stop building the relation in locals that are only committed after the loop, and instead update blocking_allocation_groups_ and activation_dependencies_ in place, so that a re-entrant OnActivationDependencyResolved() observes — and can correctly erase from — the state that the groups have already been told about:

--- a/components/viz/service/surfaces/surface.cc
+++ b/components/viz/service/surfaces/surface.cc
@@ void Surface::UpdateActivationDependencies(const CompositorFrame& current_frame) {
-  base::flat_set<raw_ptr<SurfaceAllocationGroup, CtnExperimental>>
-      new_blocking_allocation_groups;
-  std::vector<SurfaceId> new_activation_dependencies;
+  // |blocking_allocation_groups_| and |activation_dependencies_| are updated in
+  // place below rather than being built in locals and committed after the loop.
+  // UpdateLastPendingReferenceAndMaybeActivate() is re-entrant and can call
+  // back into Surface::OnActivationDependencyResolved() for a group registered
+  // by an earlier iteration. With the members still empty, that callback's
+  // erase() calls are silent no-ops while the group has already removed this
+  // surface from its |blocked_embedders_|, leaving this surface holding a
+  // group that has no record of it. The group is then garbage collected while
+  // this surface still dereferences it (see Surface::ActivateFrame()).
   bool bypass_outdated_surface_activation =
@@
-    if (new_blocking_allocation_groups.contains(group))
+    if (blocking_allocation_groups_.contains(group))
       continue;
@@
     if (group) {
       group->RegisterBlockedEmbedder(this, surface_id);
-      new_blocking_allocation_groups.insert(group);
+      blocking_allocation_groups_.insert(group);
     }
@@
-    new_activation_dependencies.push_back(surface_id);
+    activation_dependencies_.insert(surface_id);
   }
-  activation_dependencies_ = std::move(new_activation_dependencies);
-  blocking_allocation_groups_ = std::move(new_blocking_allocation_groups);
 }

Note for owners: this trades the single sorted-vector assignment for per-element base::flat_set::insert(). activation_dependencies is small and bounded in practice, but if that cost matters the same invariant can be restored by splitting the loop into a non-re-entrant “compute and register” pass followed by a second pass that performs the UpdateLastPendingReferenceAndMaybeActivate() calls after the members are committed.

Two hardening changes are worth making alongside it, independently of this bug:

• promote DCHECK(blocked_embedders_.count(surface)) in SurfaceAllocationGroup::UnregisterBlockedEmbedder to a CHECK, so a torn relation fails loudly in release instead of silently leaking a stale pointer;
• change base::flat_map<Surface*, SurfaceId> blocked_embedders_ (surface_allocation_group.h:170) to raw_ptr<Surface> keys, matching surfaces_ and active_embedders_ in the same class.

The cause

What version of Chrome have you found the security issue in?

153.0.7978.0

Is the security issue related to a crash?

Yes, it is related to a crash.

Choose the type of vulnerability

Memory Corruption (in a non-sandboxed process)

How would you like to be publicly acknowledged for your report?

Ngoc Hieu