~SourceSurfaceRecording() unconditionally called mRecorder->RemoveStoredObject(this) and mRecorder->RecordEvent(RecordedSourceSurfaceDestruction(...)) directly, from whatever thread released the surface’s last reference. The recorder’s stored-object bookkeeping and event stream are main-thread-only state; when the surface was destroyed off the main thread (e.g. a RefPtr drop on a worker/IPC thread), these calls mutated recorder state concurrently with the main thread, racing the recorder’s internal structures and operating on objects the main thread may be tearing down — a use-after-free / data race on recorder state.

The patch makes the destructor thread-aware. On the main thread it behaves as before (RemoveStoredObject(self) + RecordEvent(...) + return). Off the main thread it instead enqueues the same work via mRecorder->AddPendingDeletion([recorder = mRecorder.get(), self]() { recorder->RemoveStoredObject(self); recorder->RecordEvent(...); }), so the recorder is only ever touched on the correct thread. The comment notes the recorder owns the deletion, so the lambda captures a raw recorder pointer without an extra strong ref. The advisory’s “use-after-free in Graphics” is substantiated: the fix eliminates off-main-thread mutation of recorder state during surface destruction.

The code runs in the graphics recording path (content/GPU process, inferred). The diff substantiates a use-after-free/data race: the surface destructor mutated main-thread-only recorder state from arbitrary threads, now deferred via AddPendingDeletion. Privilege/preconditions: an attacker must cause a recorded surface to be destroyed off the main thread while the recorder is active (a timing/threading condition). Strength beyond a UAF/race is inferred. The advisory rates it moderate.