Project Fortify, an experimental security project, has identified the following potential security issue. If you’re a feature owner CC-ed on this bug, please do your best to review these reports. Please see https://chromium.googlesource.com/chromium/src/+/main/docs/security/ai-generated-security-bugs-faq.md for more information.

Overview: A potential publication race exists in SkTypeface_Mac on macOS and iOS, where the mutable member fStream is lazily initialized within an SkOnce block but read raw in onOpenExistingStream and onMakeClone without synchronization. Because SkTypeface instances are shared process-wide via a global cache, concurrent reads and writes can occur across threads. On weak memory architectures like ARM64, this can lead to virtual method dispatch on a partially-initialized object, potentially causing memory corruption.

Affected files:

• third_party/skia/src/ports/SkTypeface_mac_ct.cpp
• third_party/skia/src/ports/SkTypeface_mac_ct.h

Estimated timestamp from git blame: 2019-12-13

Description

A potential thread-safety data race and publication race exists in SkTypeface_Mac (used on macOS and iOS) due to unsynchronized concurrent access to the mutable member fStream.

Root Cause Analysis

In third_party/skia/src/ports/SkTypeface_mac_ct.h, fStream and its initialization tracker fInitStream are declared as follows:

mutable std::unique_ptr<SkStreamAsset> fStream;
mutable SkOnce fInitStream;

1. Writer Thread (onOpenStream): Inside onOpenStream (third_party/skia/src/ports/SkTypeface_mac_ct.cpp), fStream is lazily initialized inside an SkOnce lambda block:

std::unique_ptr<SkStreamAsset> SkTypeface_Mac::onOpenStream(int* ttcIndex) const {
    *ttcIndex = 0;
    fInitStream([this]{
        if (fStream) { return; }
        ...
        fStream = std::make_unique<SkMemoryStream>(std::move(streamData)); // Plain non-atomic store
    });
    return fStream->duplicate();
}

2. Reader Threads (onOpenExistingStream and onMakeClone): Two other const methods read fStream directly without executing or checking fInitStream:

std::unique_ptr<SkStreamAsset> SkTypeface_Mac::onOpenExistingStream(int* ttcIndex) const {
    *ttcIndex = 0;
    return fStream ? fStream->duplicate() : nullptr; // Raw load, bypassing fInitStream
}

And inside onMakeClone:

return SkTypeface_Mac::Make(std::move(ctVariant), ctVariation.opsz,
                            fStream ? fStream->duplicate() : nullptr); // Raw load, bypassing fInitStream

Because SkTypeface is designed and documented as thread-safe (include/core/SkTypeface.h:52) and shared process-wide via a global cache (gTFCache in SkTypeface_Mac::Make), different threads (such as the main thread and a worker thread) can hold references to the exact same typeface instance.

Concurrency and Publication Risk on ARM64

On weakly ordered memory architectures like ARM64 (Apple Silicon), the raw store of the newly created SkMemoryStream pointer into fStream inside the SkOnce block can be reordered relative to the initialization of the stream object’s internal fields (such as its virtual table pointer vptr and data buffers).

Since the reader threads (onOpenExistingStream and onMakeClone) load fStream raw without any synchronization barrier or checking the SkOnce state, a concurrent thread can observe a non-null but partially initialized/stale SkMemoryStream object. When the reader thread subsequently attempts to call the inline duplicate() helper—which internally performs a virtual method call to onDuplicate()—it will dereference a stale or uninitialized vptr, resulting in an indirect jump to an arbitrary address and potential Remote Code Execution (RCE) in the sandboxed renderer process.

Potential Trigger Steps

Note: These are potential steps based on static analysis; our tooling agent does not currently have the capability to run code or verify a live Proof of Concept.

1. A webpage renders text using a variable system font on the main thread, resulting in its registration within the process-global gTFCache in SkTypeface_Mac::Make.
2. A concurrent worker thread (e.g., executing OffscreenCanvas rendering) requests the same font and calls makeClone() to adjust variations (such as optical sizing opsz), which invokes onMakeClone and reads fStream raw.
3. Concurrently, the main thread performs an action that triggers font serialization or printing (e.g., window.print() or via the Local Font Access API), invoking onOpenStream to lazily construct and store fStream under the SkOnce guard.
4. If the worker thread’s read of fStream interleaves during the write window on ARM64, it accesses the partially published object, leading to a crash or control flow hijack via virtual dispatch.

Suggested Fix

To guarantee proper happens-before ordering and synchronization, ensure that fInitStream is always invoked prior to reading fStream in both onOpenExistingStream and onMakeClone:

std::unique_ptr<SkStreamAsset> SkTypeface_Mac::onOpenExistingStream(int* ttcIndex) const {
    *ttcIndex = 0;
    fInitStream([]{}); // Ensure stream initialization has completed and barriers are retired
    return fStream ? fStream->duplicate() : nullptr;
}

Evaluated with Chrome root at commit: e9507a33bb4148ee071aaaf8a7e9ad68770359bf

Results so far have been promising, but there can be wrong deductions. Feel free to adjust as follows:

• If you are familiar with the severity guidelines, you may adjust the severity.
• If this is a false positive, and there’s no work to be done, please close as WAI.
• If there is work to do here but not a vulnerability, please change the issue type to Task/Bug/FR.

Data from false positives will be used to improve accuracy over time. And please feel free to reach out to me directly if you have concerns or feedback on the project.