[1] Nested DrawDisplayList replay falls back to the singleton ControlFactory

HighWebCore display-list replayUAF

The per-thread isolation held at every level except the one that made levels.

fc4afc4

High. A per-context isolation handle that stops propagating at exactly one nesting boundary collapses four GPU-process render threads onto one shared AppKit cell set. Escalation is gated on the attacker already holding code execution in WebContent — from there the singleton fallback is deterministic, only the interleaving is not.

Cross-thread isolation in WebKit's GPU-process rendering pipeline is normally maintained by giving each rendering client its own copy of the platform objects it draws with, so non-thread-safe native widgets are never touched by two threads at once. Each RemoteRenderingBackend — the GPU-side object that owns one client's 2D rendering resources — runs on its own dedicated work-queue thread and replays recorded drawing commands there. Those recorded commands include DrawControlPart items, which render native form controls through a ControlFactory handed in per replay precisely so that the process-wide ControlFactory::singleton() never gets touched from a render thread.

The angle: a compromised renderer can wrap control-drawing commands one level deeper and make four GPU-process threads mutate the same shared AppKit cell objects simultaneously, which the commit message reports as a concurrent use-after-free.

The commit message is direct about both mechanism and reachability:

DisplayList::applyItem() only special-cases DrawControlPart, so a nested DrawDisplayList item falls through to item.apply(context) and calls the single-arg GraphicsContext::drawDisplayList, which substitutes ControlFactory::singleton(). A compromised WCP can wrap DrawControlPart items in a nested DrawDisplayList and replay it on multiple RemoteRenderingBackends, racing the singleton ControlFactoryMac's shared NSCell state across GPU-process work-queue threads.

Source/WebCore/platform/graphics/displaylists/DisplayListItem.cpp

Source/WebCore/platform/graphics/displaylists/DisplayListItems.cpp

Source/WebCore/platform/graphics/controls/ControlPart.cpp

LayoutTests/ipc/nested-display-list-draw-control-part-crash.html

Patch Details

Three coordinated changes. DisplayList::applyItem() gains a new switchOn arm for DrawDisplayList that forwards the replay-scoped ControlFactory& (item.apply(context, controlFactory)), alongside the pre-existing special cases for DrawControlPart (factory) and SetCTM (base transform); previously DrawDisplayList matched the generic [&](const auto& item) { item.apply(context); } fallback. DrawDisplayList::apply() changes signature from apply(GraphicsContext&) const to apply(GraphicsContext&, ControlFactory&) const, and its body switches from context.drawDisplayList(m_displayList) — the form that carries no replay-scoped factory into the nested list — to context.drawDisplayList(m_displayList, controlFactory).

ControlPart::setOverrideControlFactory() moves from an inline header setter to an out-of-line WEBCORE_EXPORT definition in ControlPart.cpp that early-returns when the factory is unchanged and, when it does change, clears the cached m_platformControl (std::unique_ptr<PlatformControl>) so a PlatformControl manufactured by the previous factory is not reused under the new one. Collateral: a new regression test driving the GPU process directly over the IPC Testing API, plus a glib TestExpectations skip entry.

Incomplete propagation of a per-context isolation handle through a recursive dispatch table, so the nested case silently falls back to a process-wide singleton.

Background

Where this lives. WebCore records drawing operations into a DisplayList — a Vector<Item> where Item is a variant of small command classes (Save, Clip, DrawControlPart, DrawDisplayList, ...). Replay walks the vector and calls DisplayList::applyItem(), which uses WTF::switchOn to dispatch each variant alternative to its apply() method.

Nesting. DrawDisplayList is a display-list item whose payload is another Ref<const DisplayList>, so display lists can nest and replay is recursive.

The control-drawing layer. ControlPart is a platform-independent description of a native form control (button, checkbox, radio, menu list, search field). It obtains a PlatformControl — the platform-backed drawing object — from a ControlFactory via createPlatformControl(), caches it in mutable std::unique_ptr<PlatformControl> m_platformControl, and drives it through updateCellStates() and draw(). ControlPart::controlFactory() resolves to m_overrideControlFactory when one is installed and otherwise to the process-wide ControlFactory::singleton(). On macOS the concrete factory is a ControlFactoryMac backed by AppKit NSCell objects.

GPU-process rendering IPC. WebContent creates a RemoteRenderingBackend per rendering backend over a stream connection. RemoteRenderingBackend's constructor creates its own IPC::StreamConnectionWorkQueue, and its handlers assertIsCurrent(workQueue()), so each backend processes its messages on a dedicated thread. RemoteDisplayListRecorder records incoming RemoteGraphicsContext messages into a DisplayList::RecorderImpl, SinkDisplayListRecorderIntoDisplayList freezes it into a replayable DisplayList, and RemoteImageBuffer's context replays it.

ThreadSafeRefCounted. A WTF base class giving atomic reference counting. It guarantees the refcount is race-free; it does not make the object's own member state thread-safe.

IPC Testing API. A test-only WebKit facility (IPCTestingAPIEnabled=true) letting a layout test send raw, hand-crafted IPC messages to other processes — used to simulate what a compromised WebContent process could send.

Analysis

The bug is an isolation-context propagation failure in a recursive dispatch table, which surfaces as a data race on non-thread-safe platform state.

  Backend A thread        Backend B thread        shared singleton
  ────────────────        ────────────────        ────────────────
  replay outerDL          replay outerDL
    factory = A_factory     factory = B_factory
    item: DrawDisplayList   item: DrawDisplayList
      └► generic arm          └► generic arm
         apply(context)          apply(context)     ControlFactoryMac
           no factory ─────────────┬───────────────► m_buttonCell
                                   │                 m_checkboxCell
    30x DrawControlPart            │                 m_radioCell
      updateCellStates(20px) ──────┤                      ▲
                        (200px) ───┘   concurrent RMW ─────┘

applyItem() threads a per-replay ControlFactory& precisely so that control-drawing work stays isolated to the calling context's own factory instance. It implements that threading with a WTF::switchOn enumerating only the item types needing extra arguments — DrawControlPart and SetCTM — and routes everything else to the generic item.apply(context) arm. DrawDisplayList is the one recursive item: it re-enters the replay machinery for a whole nested DisplayList. Because it was not enumerated, it landed in the generic arm and called GraphicsContext::drawDisplayList(m_displayList) with no factory argument, so the nested replay proceeded without a replay-scoped factory installed on its parts. The isolation invariant held for depth-0 items and was silently dropped at every nesting boundary.

Downstream, ControlPart::controlFactory() returns m_overrideControlFactory ? *m_overrideControlFactory : ControlFactory::singleton(), so once the override is not installed for a nested item, every DrawControlPart inside the nested list resolves to the singleton. ControlPart::platformControl() then lazily calls createPlatformControl(), asking that factory for a PlatformControl, and ControlPart::draw() calls updateCellStates(borderRect.rect(), style) followed by draw(...) on it. ControlFactory is ThreadSafeRefCounted, which makes its refcount safe but says nothing about the platform state it vends. On macOS the singleton is a ControlFactoryMac whose lazily-created NSCell members and shared control view are mutated by updateCellStates/draw — per the new test's inline comments and the commit message. Concurrent replay on several work-queue threads therefore mutates and reads the same platform objects with no synchronization. (DrawControlPart::apply(GraphicsContext&, ControlFactory&) installing the passed factory on the part via setOverrideControlFactory is a strong inference from ControlPart::controlFactory() plus the second fix hunk rather than a body visible in the supplied context.)

The second half of the fix closes a related staleness hole: ControlPart caches its PlatformControl in mutable std::unique_ptr<PlatformControl> m_platformControl, and the old inline setOverrideControlFactory swapped the factory without invalidating that cache, so a part could keep using a PlatformControl — and the platform state behind it — manufactured by a different factory after the override changed.

The regression test is the trigger recipe, and its structure is worth reading step by step:

1. CreateRenderingBackend four times, so four RemoteRenderingBackends exist, each with its own IPC::StreamConnectionWorkQueue thread.
2. Per backend, CreateDisplayListRecorder, then 30 DrawControlPart messages cycling ButtonPart with Button/DefaultButton/PushButton, ToggleButtonPart with Checkbox/Radio, plus MenuListPart and SearchFieldPart — the test's comments state these map onto distinct lazily-created cell members of the macOS factory. SinkDisplayListRecorderIntoDisplayList freezes this as innerDL.
3. Per backend, a second recorder receives a single DrawDisplayList(innerDL) message and is sunk into outerDL — this is the nesting step.
4. A CG-backed ImageBuffer is created per backend, and its RemoteGraphicsContext is told DrawDisplayList(outerDL) 0x40 times on each of the four connections.

The outer replay enters applyItem() with the backend's own ControlFactory; the single DrawDisplayList item matches the generic arm, calls context.drawDisplayList(m_displayList) with no factory, and the nested replay of the 30 DrawControlPart items resolves through ControlPart::controlFactory()'s singleton branch. Each backend passes a different control size (20, 200, 40, 120), so ControlPart::draw()'s platformControl->updateCellStates(borderRect.rect(), style) writes conflicting geometry into the same shared cells from four threads at once.

On exploitability: this is reachable only from a compromised WebContent process — the trigger requires emitting RemoteRenderingBackend/RemoteGraphicsContext IPC by hand, and normal WebKit recording code would install the per-context factory correctly. From that position, the nested-replay path deterministically collapses onto ControlFactory::singleton() across independent work-queue threads. The immediate observable effect is unsynchronized concurrent read-modify-write of shared control-drawing state, plus concurrent lazy initialization of the factory's cached members; a torn or double initialization of a lazily created member would drop or double-release the earlier instance. If the raced state includes reference-counted Objective-C objects whose retain/release the concurrent paths interleave, an over-release could free a still-referenced cell or control view, and the next updateCellStates/draw on another thread could then operate on freed memory — the commit message names exactly this outcome ("Concurrent NSCell UAF"). The retain/release paths of the shared control state are not part of the supplied context, so that step is relayed as an attributed projection. Converting it into a controlled primitive would additionally require grooming the GPU-process heap so the freed AppKit allocation is reclaimed with attacker-shaped data before the surviving thread dereferences it; the supplied context contains no evidence about the allocation size class or field layout of those objects.

This vulnerability weakens thread-isolation inside the GPU process, the trust boundary that keeps a compromised WebContent process from corrupting a higher-privileged process with access to IOSurfaces, media, and GPU drivers. The security model assumption at stake is that each RemoteRenderingBackend's replay work-queue thread touches only its own per-context ControlFactory, so non-thread-safe platform control state is never shared across threads; nested DrawDisplayList replay violated that assumption by collapsing all backends onto the singleton. An attacker with code execution in WebContent could use this to induce unsynchronized concurrent mutation of shared platform objects in the GPU process — memory corruption at a privilege level the sandbox is supposed to protect, i.e. a candidate link in a sandbox-escape chain rather than a bug reachable directly from a web page.

Insight

The bug lives in the shape of the dispatcher, not in any one item's logic. applyItem() is an exhaustive-looking WTF::switchOn whose default arm makes forgetting a case silent rather than a compile error — and the one item type that recursively re-enters replay is exactly the one that most needs the extra context propagated. Any dispatch table with a catch-all arm plus a recursive alternative has this hazard: the invariant is enforced at every level except the one that creates new levels. A structurally safer form would remove the auto fallback so the compiler forces each new item type to declare which replay context it needs, or make the factory-less GraphicsContext::drawDisplayList form unavailable to replay code so the singleton fallback cannot be reached implicitly. Note also that ControlFactory being ThreadSafeRefCounted is quietly misleading here: it makes the handle safe to share across threads while the platform state behind it is not, which is precisely the confusion a per-context factory is meant to prevent.

The discovery angle reads as targeted manual auditing of the GPU-process display-list IPC surface with a strong variant-analysis component: the glib TestExpectations hunk shows an adjacent pre-existing test, ipc/remotedisplaylistrecorder-drawcontrolpart-slidertrackpart-crash.html, meaning DrawControlPart replay had already been probed. The natural follow-up is to ask which replay paths reach DrawControlPart without the per-context factory. The test's hand-rolled StreamConnection with an extended timeout and its CoreIPC.typeInfo override for WebCore::PlatformColorSpace indicate hands-on IPC harness work rather than an off-the-shelf fuzzer.

Audit directions

• Recursive dispatch table dropping per-invocation context. A dispatcher threads context to enumerated cases but a catch-all arm drops it for anything not explicitly listed — the invariant holds at every level except the recursive one that creates new levels. Narrow: audit DisplayList::applyItem() in Source/WebCore/platform/graphics/displaylists/DisplayListItem.cpp for any other item alternative that transitively re-enters replay or drawing with implicit defaults, and enumerate the callers of the factory-less GraphicsContext::drawDisplayList form to confirm none remain on a replay path; the tell is an item whose apply() reaches a function with defaulted or omitted context parameters. Wider: the same class shows up in any WebKit visitor over a variant that has a [&](const auto&) fallback while sibling arms receive extra state — check the other WTF::switchOn sites in the display-list, filter (FilterResults), and serialization layers, and check shouldDumpItem/dumpItem in the same file for the mirrored omission; the tell in code-search results is a switchOn whose lambdas do not all take the same argument list. Widest: the reusable invariant is when a dispatcher carries per-invocation context, every recursive alternative must be an enumerated case, and the default arm must be unable to reach a context-defaulting API. This applies to any interpreter or IR walker with a default case and a nested/compound node type (V8/SpiderMonkey bytecode visitors, LLVM pass switch-on-opcode with a default, Rust match with _ => over an AST with a Block variant). Match tell to carry across codebases: a default/_/auto arm coexisting with a self-recursive node kind and a per-call context parameter.

• Per-context isolation object with a process-wide singleton fallback. Any path that forgets to install the override silently degrades to shared state instead of failing. Narrow: grep Source/WebCore/platform/graphics/controls/ and the GPU-process graphics code for ControlFactory::singleton() and for every caller of ControlPart::setOverrideControlFactory, and verify each replay/drawing entry point installs the per-context factory before any ControlPart::draw/sizeForBounds/rectForBounds call — the tell is a foo ? *foo : Foo::singleton() accessor whose override is set by only some of its callers. Wider: the same shape appears wherever WebKit pairs an instance handle with a ::singleton() default reachable from GPU-process work-queue threads — audit IOSurfacePool, FontCache, and the RemoteSharedResourceCache accessors reached from RemoteRenderingBackend's assertIsCurrent(workQueue()) handlers for the same optional-override-with-singleton-default pattern. Widest: the invariant is a fallback default must never be a shared mutable object when the override exists specifically to provide isolation — a default should be either per-invocation or a hard error. This holds for thread-local vs global allocators, per-request vs global DI container scopes, per-connection vs process-global caches in any server, and Go's context.Background() used where a request context was intended. Match tell: any accessor of the form return override ? *override : Global::instance();.

• Lazily-built cache keyed implicitly on a mutable owner. Changing the owner does not invalidate the cache — the fix's m_platformControl = nullptr in ControlPart::setOverrideControlFactory is the corrective. Narrow: audit ControlPart subclasses and the PlatformControl hierarchy for other state derived from controlFactory() that survives an override swap, and check whether a ControlPart deserialized from IPC can be replayed under two different factories within one process — the tell is a mutable std::unique_ptr<X> m_x; populated in a const getter from a member that has a public setter. Wider: the same shape covers any WebCore object caching a platform-derived resource whose producer is settable at runtime — look for mutable cached members in Source/WebCore/platform/graphics/ whose creator is reachable through a settable factory, context, or device handle, and confirm each setter clears the cache. Widest: the invariant is every setter for a value that a memoized field was derived from must invalidate that field — memoization without a declared dependency set is the general failure, visible in React useMemo dependency arrays, ORM identity maps that outlive a connection swap, and GPU pipeline-state caches keyed on a device that can be recreated. Match tell: a memoized field whose derivation reads a member that has a public mutator, with no invalidation in that mutator.

• Refcount-safe handle, non-thread-safe payload. A type deriving from a thread-safe refcounting base leads readers to assume the object's contents are safe to share. Narrow: inspect ControlFactory (ThreadSafeRefCounted<ControlFactory>) and ControlPart (ThreadSafeRefCountedAndCanMakeThreadSafeWeakPtr<ControlPart>) implementations for mutable platform state touched during draw, and check whether any of them are reachable from more than one RemoteRenderingBackend work-queue thread simultaneously; the tell is a ThreadSafe*RefCounted class with non-atomic mutable members and no lock. Wider: enumerate the ThreadSafeRefCounted types reachable from GPU-process replay (image buffers, font/glyph caches, gradient/pattern objects, filter results) and ask for each whether thread-safety was ever established beyond the refcount — code-search shape: a ThreadSafeRefCounted base paired with non-const methods that write members. Widest: the invariant is atomic reference counting proves nothing about the object's internal invariants under concurrent access — the same conflation appears with Arc<T> misused where Arc<Mutex<T>> is needed, shared_ptr treated as a concurrency guarantee, and Java objects assumed safe because their handle is volatile. Match tell: a type whose only concurrency affordance is in its refcounting base class, with mutating methods and no synchronization primitive anywhere in the declaration.