ExtractSubrect checked !mImage and then proceeded to build an SkImageInfo and copy pixels out of mImage without holding mChangeMutex. Because the backing SkImage can be released/replaced on another thread, mImage could be non-null at the check yet freed before/while the copy reads its pixels — a classic time-of-check/time-of-use race that dereferences freed snapshot memory. The patch reorders and locks: it first validates the rectangle (aRect.IsEmpty() || !GetRect().Contains(aRect)), then acquires MutexAutoLock lock(mChangeMutex), and only then re-checks !mImage and performs the copy. The comment states the intent directly: “Shared snapshot pixels must remain stable until the copy completes.” Holding the lock across the null-check and the pixel copy prevents another thread from releasing mImage mid-read.

The advisory labels this a use-after-free in Graphics, which the diff supports: the missing lock permits a concurrent release of the backing image during the extract/copy. The bug is fundamentally a data race whose sink is a use-after-free of the Skia snapshot buffer.

This runs in a graphics context (content or GPU/compositor process, inferred). The primitive is a concurrent use-after-free of a Skia snapshot buffer during ExtractSubrect, i.e. reading freed memory, which can leak or corrupt heap state. No privilege beyond driving the relevant surface/extract operation is needed; the exploit requires winning the release-vs-copy race (a timing precondition). Strength beyond a UAF read is inferred. The advisory rates it moderate.