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 without the security team.

Overview: A race condition exists in GlobalCache::findGraphicsPipeline where a stack-local raw pointer to a cache entry is dereferenced after its protecting spinlock is released. This can result in a Use-After-Free if another thread evicts the entry from the LRU cache during the window between lock release and dereference. An attacker could potentially use this to execute an arbitrary 64-bit atomic increment, leading to RCE in the unsandboxed GPU process.

Affected files:

• third_party/skia/src/gpu/graphite/GlobalCache.cpp

Estimated timestamp from git blame: 2025-10-29

Description

A potential Use-After-Free (UAF) vulnerability exists in the Graphite backend of Skia, specifically within GlobalCache::findGraphicsPipeline. The function retrieves a raw pointer to an entry in fGraphicsPipelineCache (an SkLRUCache) while holding fSpinLock. However, it releases the lock before dereferencing this pointer.

In third_party/skia/src/gpu/graphite/GlobalCache.cpp:

188:     sk_sp<GraphicsPipeline>* entry = nullptr;
189:     {
190:         SkAutoSpinlock lock{fSpinLock};
191: 
192:         entry = fGraphicsPipelineCache.find(key);
... // Bookkeeping performed under lock
242:         }
243:     } // fSpinLock is released here
244: 
245:     if (entry) {
246:         this->invokePipelineCallback(ContextOptions::PipelineCacheOp::kPipelineFound, entry->get());
247:         return *entry;
248:     }

SkLRUCache::find() returns a raw pointer to the fValue field within a heap-allocated Entry node. Because fSpinLock is released at line 243, a concurrent thread can acquire the lock and perform operations that evict or remove the entry from the cache. For example, a concurrent call to addGraphicsPipeline calls fGraphicsPipelineCache.insert(), which evicts the LRU tail if the cache size limit (default 256) is exceeded. Eviction results in the heap memory backing the Entry being deleted, leaving entry as a dangling pointer.

Impact & Exploitability

In Chromium’s GPU process, GlobalCache is shared across multiple threads (e.g., Viz compositor thread and GPU main thread). This provides a mechanism for concurrent access where one thread can trigger an eviction while another is returning a pipeline from the cache.

This issue is not protected by MiraclePtr/BRP because entry is a stack-local raw pointer within Skia code, which is currently excluded from the MiraclePtr rewriter. Furthermore, because there are no raw_ptr references to the cache entry memory, PartitionAlloc does not quarantine the memory upon deletion, making it immediately available for reallocation.

When a race occurs, the dereference at line 247 (return *entry;) accesses freed memory. This invokes the copy constructor for sk_sp<GraphicsPipeline>.

The following steps suggest how an attacker could potentially exploit this:

1. The attacker creates 256 unique graphics pipelines to fill the LRU cache to its limit.
2. The attacker triggers findGraphicsPipeline on Thread 1 for an existing pipeline (Pipeline A), pausing execution immediately after the fSpinLock is released.
3. Concurrently on Thread 2, the attacker triggers the creation of 256 new unique pipelines via addGraphicsPipeline. This evicts Pipeline A from the cache and deletes its Entry node.
4. The attacker sprays the GPU process heap to reclaim the freed Entry chunk, placing a fake 64-bit pointer (P) at the exact memory offset corresponding to the former fValue field.
5. Thread 1 resumes and executes return *entry;.
6. The sk_sp copy constructor reads the attacker-controlled pointer P and calls SkSafeRef(P).
7. SkSafeRef executes P->ref(). Crucially, ref() in skgpu::graphite::Resource (the base class of GraphicsPipeline) is a non-virtual inline method. This means the compiler emits a direct static function call, completely bypassing the need for the fake object to have a valid vtable.
8. Resource::ref() executes an atomic 64-bit addition: fRefs.fetch_add((uint64_t)1 << 2, std::memory_order_relaxed); at offset +8 from P.

The attacker has achieved a pristine, highly reliable arbitrary 64-bit atomic increment primitive. By setting P+8 to the address of an array bound, string length, or index within a critical GPU process object, the attacker can surgically inflate the bound by 4. This provides out-of-bounds read and write capabilities, allowing them to bypass ASLR and hijack control flow. Because the Chromium GPU process is unsandboxed and has elevated privileges, achieving RCE within it constitutes a full sandbox escape (Severity 0).

Recommendation

The implementation should copy the sk_sp<GraphicsPipeline> value into a local variable while the lock is still held, and then use that local variable outside the lock scope. This is already the pattern used correctly in GlobalCache::findComputePipeline in the same file.

    sk_sp<GraphicsPipeline> pipeline;
    {
        SkAutoSpinlock lock{fSpinLock};
        if (auto* entry = fGraphicsPipelineCache.find(key)) {
            // ... bookkeeping ...
            pipeline = *entry;
        } else {
            // ... cache miss logic ...
        }
    }

    if (pipeline) {
        this->invokePipelineCallback(ContextOptions::PipelineCacheOp::kPipelineFound, pipeline.get());
        return pipeline;
    }
    return nullptr;

Evaluated with Chrome root at commit: 137d451a126685dd5010e6609db9f6d4a78d8234

Results so far have been promising, but there can be wrong deductions. If this proves to be a false positive, please close as WAI; 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.