[6] WebXRSystem re-posts a completion handler past the reference that protected it

MediumWebCore WebXRUAF

2b68a68

Medium. The read is real, and the permission path adds a one-byte store into freed storage — but reaching either requires the iframe detached and its wrapper collected inside the window between the reply lambda's release and the queued main-thread task, a window the page influences without directly timing.

Object lifetime across an asynchronous callback boundary is normally kept safe by having the callback carry its own strong reference to the receiver, so the object cannot be destroyed while a reply is in flight. WebXRSystem — the implementation of navigator.xr, installed as a supplement on a frame's Navigator — brokers device enumeration and session requests to the platform XR stack through asynchronous ChromeClient calls. Its enumeration reply lambda captures protectedThis, a strong reference that keeps the system alive for exactly as long as the reply body runs.

The angle: a page that detaches an iframe mid-enumeration and lets its navigator.xr wrapper be collected can have the re-posted continuation read device state out of freed memory, and on the session-request path write into it.

Patch Details

Three call sites and one guard change. obtainCurrentDevice and isSessionSupported, which call ensureImmersiveXRDeviceIsSelected directly, previously captured only raw this in the completion handlers they supply; both now carry their own strong reference. requestSession reaches the same re-post one level deeper — the lambda it holds a protectedThis for is the completion handler it hands to obtainCurrentDevice, which is the callback that obtainCurrentDevice's continuation forwards — and gets the same treatment. Separately, the resolveFeaturePermissions reply lambda's combined if (!weakThis || !requestedFeatures) guard is split, so the receiver-dead branch no longer falls into the body that performs m_pendingImmersiveSession = false.

A strong reference scoped to the reply body rather than to the deferred task that reply body creates, so ownership stops one hop short of the code that dereferences the receiver.

Background

navigator.xr and supplements. WebXRSystem is an ActiveDOMObject and EventTarget installed as a Navigator supplement through NavigatorWebXR. The strong owner is NavigatorWebXR::m_xr, a RefPtr<WebXRSystem> per NavigatorWebXR.h, reachable from a frame's navigator.xr.

Device selection flow. ensureImmersiveXRDeviceIsSelected dispatches an enumerateImmersiveXRDevices call through Chrome::client() and receives a reply lambda when enumeration finishes.

makeScopeExit and callOnMainThread. makeScopeExit runs a callable when the enclosing scope unwinds, whatever the exit path. callOnMainThread posts a callable onto the main run loop as a separate task — it does not run inline, so the posting scope has already unwound by the time the task executes.

Ref, WeakPtr, and ThreadSafeWeakPtr. A Ref/RefPtr keeps its referent alive; a WeakPtr does not and evaluates false once the referent is destroyed. ThreadSafeWeakPtr<PlatformXR::Device> — the type of m_activeImmersiveDevice — is the cross-thread variant, promoted to a RefPtr at the point of use.

Analysis

The root cause is that ownership was propagated one hop short. The reply lambda for enumerateImmersiveXRDevices captures protectedThis = protect(*this), guaranteeing the WebXRSystem is alive for the duration of the reply. But inside that reply, a makeScopeExit does callOnMainThread(WTF::move(callback)) — the caller-supplied CompletionHandler is moved out and re-posted as its own task. Once the reply lambda is destroyed, its protectedThis releases, and the re-posted task runs with whatever ownership the caller's callback happens to carry. Both direct callers carried raw this.

  ensureImmersiveXRDeviceIsSelected()
    +- ChromeClient::enumerateImmersiveXRDevices(reply)
         reply lambda: [protectedThis = protect(*this)]  -- strong --+
  reply runs on main thread                                          |
    +- makeScopeExit: callOnMainThread(WTF::move(callback))          |
         (caller's CompletionHandler re-posted as its own task)      |
  reply lambda destroyed ---------------------------------------------+
    protectedThis released              <-- failure window opens
  iframe detached; wrapper collected
    NavigatorWebXR::m_xr RefPtr dropped -> WebXRSystem freed
  queued task runs
    reads m_activeImmersiveDevice out of freed storage

The missing invariant is general: a callable forwarded past the lifetime of the frame that protects the receiver must carry its own strong reference. The Ref in the reply lambda protects the wrong scope — it covers the reply body, not the deferred task the reply body creates.

Detaching the iframe and collecting its JS wrapper is expected to destroy the Navigator supplement and drop the RefPtr<WebXRSystem>. If that happens after the reply lambda's protectedThis releases but before the queued callOnMainThread task runs, the task dereferences freed storage. Concretely: isSessionSupported's continuation read m_activeImmersiveDevice out of the dead object and constructed a RefPtr from it, and obtainCurrentDevice's continuation read the same member and passed it onward.

The resolveFeaturePermissions defect is independent and sits in the same function. That reply lambda held weakThis = WeakPtr { *this } and raw this. The combined guard if (!weakThis || !requestedFeatures) funnelled both the receiver-is-dead case and the permission-denied case into one body, and that body executed m_pendingImmersiveSession = false — a store at a fixed offset into the WebXRSystem allocation, performed precisely in the branch where the null weakThis proves the object no longer exists. The null check was present; its failure branch still touched members.

So the reachable primitives are a read of freed storage on the enumeration paths and a one-byte write at a fixed offset into a freed allocation on the permission path. Exploiting either requires landing a controlled allocation in the freed storage between the release and the queued task, which the page can attempt through allocation pressure but cannot directly synchronise with — the interval is bounded by main-run-loop scheduling rather than by anything script sequences. The fixed-offset write is the more useful of the two if the reclaiming object's layout can be arranged.

This vulnerability weakens the lifetime guarantee that page script expects across the XR device-selection boundary: an object whose owning frame has been torn down and collected remains addressable, and writable, from work the frame scheduled before it died.

Audit directions

Ownership that stops at the reply boundary. The dangerous shape is a lambda that holds a protectedThis and then moves a different callable out to a deferred task — the protection covers the posting scope, not the posted one. Audit ChromeClient async reply handlers across WebCore for makeScopeExit or direct callOnMainThread/postTask calls that move a CompletionHandler out of the reply body. In review, a capture list containing protectedThis in a function whose body posts a callback is the tell: ask what protects the callback.
Untouched callers of a patched entry point. WebXRSystem.h lists further callers of the patched entry points — WebGLRenderingContextBase::makeXRCompatible and HTMLCanvasElement::createContextWebGL — that this patch does not change. Trace their callbacks through the same re-post and confirm each carries its own strong reference.
Null-checked guards whose failure branch still touches members. A guard that proves the receiver is dead and then falls into a shared body containing member stores is a check that makes the code look safe while doing the opposite. Grep for if (!weakThis || ...) and if (!weakThis && ...) compound conditions and read the body for m_ assignments; the compound condition with a single body is the visual signature.