CVE-2026-74943 · Use-after-free in Firefox RasterImage surface discard

This directory holds an honest reproduction scaffold for a cross-thread use-after-free in mozilla::image::RasterImage::OnSurfaceDiscarded. It is meant to be run against a locally downloaded vulnerable Firefox build using only synthetic image data. It never touches any live or third party system.

Matching PoC repository: https://github.com/defineid/Revenant Writeup: writeup-rasterimage-uaf.html in this portfolio.

Facts established by disassembly during the original analysis

These were confirmed by disassembling the vulnerable build (libxul.so, Firefox 140.9.0esr) during the original research; the committed screenshot assets/writeup-uaf-disasm.png is that analysis. Function names come from the official Mozilla Breakpad symbol file for that exact build; the shipped libxul.so is stripped. They were not re-disassembled in the environment that assembled this PoC package (see Verification status).

Advisory metadata (as stated in the writeup / advisory, not independently reverified here)

Mechanism (from the real binary and the fix)

SurfaceCacheImpl::Remove notifies the owning image that a decoded surface was discarded by calling OnSurfaceDiscarded through a raw, non-owning ImageKey pointer, on a decoder / ImageIO thread, while holding the surface cache mutex. In the vulnerable build that handler:

1. Reads a single byte flag at this+0xC0 early (cmp BYTE PTR [rdi+0xc0],0x0). The writeup identifies this as mIsBeingDestroyed, an earlier mitigation.
2. Takes a strong reference to this by incrementing the RasterImage refcount at this+0x40 (lock inc QWORD PTR [rbx+0x40]). This is a plain add-ref, not an atomic add-ref-if-nonzero.
3. moz_xmalloc(0x20)-allocates a RunnableFunction that captures this (mov QWORD PTR [rax+0x10],rbx), dispatches it to a global event target (call QWORD PTR [rcx+0x28]), then releases the local reference (lock dec QWORD PTR [rbx+0x40]).

Because reading the flag and incrementing the count are two separate operations against a lock-free refcount, they can straddle the moment the main thread drops the last reference. The decoder thread then AddRefs from zero, resurrecting an object whose destructor has already committed. When the destructor finishes and frees the RasterImage, the queued runnable later runs on the main thread and reads freed storage.

The fix stops referencing the image directly: OnSurfaceDiscarded captures a strong reference to the separately refcounted ProgressTracker and recovers the image on the main thread through the tracker's weak back-reference, promoting it with an atomic add-ref-if-live; the mIsBeingDestroyed flag is removed.

Threat model

An ordinary web page in the content process drives surface-cache pressure (many discardable decoded surfaces) while releasing the frame that owns the image requests. No click, permission, extension, or pref change is required. The race is between the decoder thread's discard notification and the main thread's final release of the same image.

Prerequisites

1. A vulnerable build: Firefox before 154 or ESR before 140.14. The writeup analysis uses Firefox 140.9.0esr. Download the matching platform build from the official Mozilla archive at https://ftp.mozilla.org/pub/firefox/releases/140.9.0esr/. An ASAN build (Nightly asan or a local --enable-address-sanitizer build) makes the use-after-free observable as a clean report instead of an occasional silent crash.
2. Only synthetic image data. This harness generates its own images with a <canvas> at runtime; it loads nothing from the network.

Run

Open trigger.html in the vulnerable build, ideally from a file:// path or a local static server you control:

/path/to/firefox --new-instance --profile ./poc-profile ./trigger.html

By default the driver runs a tight microtask loop for maximum decode/release overlap. Appending ?tick=N to the URL switches it to a yielding setTimeout(N) loop that churns just as hard but lets the event loop breathe, which is what allows an automated driver to step and screenshot the page while it runs. The committed trigger-running.png was captured exactly that way, driving the local 140.11.0esr build through Marionette with ?tick=4: it shows the harness live (cycles and teardowns climbing). That build is patched, so no crash occurs; the image only proves the driver runs. On headless the off-screen images are not painted, so the "images decoded" counter stays at 0 there; a headed vulnerable build decodes them and is where the race is exercised.

Let the page run. It repeatedly decodes many distinct large images (to fill the surface cache and force eviction) while tearing down the DOM subtree that owns them (to drive the owning image's final release). This maximizes the overlap of "surface discarded" on the decoder thread with "last release" on the main thread. Races are probabilistic; leave it running.

Expected result

• Vulnerable build (before 154 / ESR 140.14): under ASAN you eventually see a heap-use-after-free whose READ frame is inside RasterImage::OnSurfaceDiscardedInternal / the dispatched runnable, with the freed frame in RasterImage::Release teardown. Without ASAN it may surface as an intermittent content-process crash.
• Fixed build (154 / ESR 140.14 and later): no use-after-free. The handler goes through the ProgressTracker weak back-reference and drops the notification when destruction has already committed.

Verification status

• Done during the original analysis (not in this packaging environment): the vulnerable libxul.so (140.9.0esr) was disassembled and every binary-level fact in the first table above was confirmed byte-for-byte against the official Mozilla symbol file; the committed assets/writeup-uaf-disasm.png is that work. The three structural claims from the writeup (early this+0xC0 flag read; lock inc AddRef at this+0x40; moz_xmalloc(0x20) runnable that captures this, dispatches, then Releases) all hold.
• NOT done in this environment: the only Firefox present here is 140.11.0esr, not the 140.9.0esr build used for the disassembly; the binary was not re-disassembled, Firefox was not launched, the race was not triggered, and no memory corruption was produced or exploited here. This scaffold is a reachability / timing driver, not a weaponized exploit. It makes no attempt at controlled code execution. Run it yourself against a local vulnerable ASAN build to capture the crash for the writeup.

Scope and ethics

This targets a locally downloaded build with synthetic, self-generated data, for a writeup of an already-patched CVE. It does not attack any live or third party service and contains no exploitation primitive beyond triggering the defect.