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: PaintImage::ContentId is minted using a 32-bit sequence number with no wraparound guard. Cycling the counter across 2^32 mints causes FrameKey collisions in shared image decode caches because cache lookups do not validate image origin or stable identity. This may allow unprivileged web content to substitute cached cross-origin image pixels into an origin-clean canvas and read them back via getImageData.

Affected files:

• cc/paint/paint_image.cc
• cc/paint/paint_image.h
• cc/tiles/gpu_image_decode_cache.cc
• cc/tiles/software_image_decode_cache_utils.h

Estimated timestamp from git blame: 2017-08-31

Summary

PaintImage::ContentId is a 32-bit signed integer (int) generated from a process-global base::AtomicSequenceNumber. When incremented past 32-bit capacity, it wraps around and repeats previously generated IDs. Image decode caches (GpuImageDecodeCache and SoftwareImageDecodeCache) key cached decoded textures solely by PaintImage::FrameKey (which is (ContentId, frame_index)) without verifying stable image IDs, origin, or source URLs. Because canvas tainting is enforced at draw-call recording time in Blink, a same-origin image colliding with a cached cross-origin image’s FrameKey will cause the victim image’s cached texture to be rendered into an origin-clean canvas, potentially allowing cross-origin pixel extraction via getImageData() or toDataURL().

Root Cause Analysis

1. 32-Bit Sequence Generator Wraparound: In cc/paint/paint_image.cc (lines 40, 110-112):

base::AtomicSequenceNumber g_next_image_content_id;
...
PaintImage::ContentId PaintImage::GetNextContentId() {
  return g_next_image_content_id.GetNext();
}

base::AtomicSequenceNumber::GetNext() executes seq_.fetch_add(1, std::memory_order_relaxed) on a 32-bit signed integer (std::atomic_int) (base/atomic_sequence_num.h:23-26). After $2^{32}$ calls, the counter wraps around and repeats previously allocated IDs. Release builds contain no checks preventing wraparound (the DCHECK_NE checks at cc/paint/paint_image.cc:360 are compiled out in production).

2. FrameKey Identity Keying in Shared Decode Caches: PaintImage::FrameKey is defined solely by (content_id_, frame_index_) (cc/paint/paint_image.h:189-209, cc/paint/paint_image.cc:501-503). In GpuImageDecodeCache::GetImageDataForDrawImage (cc/tiles/gpu_image_decode_cache.cc:2498-2516), lookup is performed on persistent_cache_.Get(draw_image.frame_key()).

GpuImageDecodeCache::IsCompatible (gpu_image_decode_cache.cc:2536-2565) validates scale and color space compatibility, but does not verify draw_image.paint_image().stable_id(), origin, or dimensions when upload_scale_mip_level == 0 (unscaled 1:1 draw). Similarly, SoftwareImageDecodeCache explicitly omits stable_id_ from key equality (cc/tiles/software_image_decode_cache_utils.h:108-112).

3. Taint Decision Timing vs Raster Substitution: Canvas tainting is checked and recorded at API invocation time in Blink based on the CanvasImageSource (third_party/blink/renderer/modules/canvas/canvas2d/canvas_2d_recorder_context.cc:2322-2324). Drawing a same-origin or data: URL image passes WouldTaintCanvasOrigin (third_party/blink/renderer/modules/canvas/canvas2d/canvas_image_source_util.cc:89-104), keeping HTMLCanvasElement::OriginClean() as true. When the canvas is subsequently rasterized in cc, PlaybackImageProvider::GetRasterContent calls GetDecodedImageForDraw (cc/raster/playback_image_provider.cc:76), which retrieves and renders the colliding cross-origin image’s texture. A subsequent call to ctx.getImageData() (third_party/blink/renderer/modules/canvas/canvas2d/base_rendering_context_2d.cc:377) succeeds because the canvas remains marked clean.

Potential Attack Scenario

(Note: These are suggested/potential steps identified through source code tracing; our tooling agent does not have the capability to execute code or run an active PoC.)

1. An attacker page loads a sensitive cross-origin image $V$ (e.g. <img src="https://victim.example.com/avatar.png">) and draws it into a temporary canvas $T$. The image is decoded and cached in GpuImageDecodeCache under FrameKey(C_v, 0).
2. The attacker reads the natural dimensions $W \times H$ via img.naturalWidth/naturalHeight.
3. The attacker uses background Web Workers to rapidly cycle g_next_image_content_id ~$2^{32}$ times using lightweight operations that mint ContentIds without filling the decode cache (such as createImageBitmap transformations via StaticBitmapImageTransform::Apply).
4. Near wraparound back to $C_v$, the attacker creates same-origin candidate images $B_i$ sized $W \times H$. The candidate image receiving ContentId == C_v shares FrameKey(C_v, 0).
5. The attacker draws $B_i$ to a clean canvas $F$ at 1:1 scale. Blink marks canvas $F$ origin-clean. During rasterization, GpuImageDecodeCache serves victim image $V$’s cached texture.
6. The attacker reads out the victim’s cross-origin pixel data via F.getContext('2d').getImageData(0, 0, W, H) without triggering a SecurityError.

Suggested Fix

1. Widen PaintImage::Id and PaintImage::ContentId from int (32-bit) to uint64_t or base::IdType64, eliminating practical counter exhaustion.
2. Alternatively (or in addition as defense-in-depth), add an immediate CHECK against counter overflow in g_next_image_content_id and g_next_image_id.
3. Include PaintImage::Id (stable_id) and image dimension checks in GpuImageDecodeCache::IsCompatible and SoftwareImageDecodeCache::CacheKey::operator== to ensure separate image instances cannot collide in the decode caches.

Evaluated with Chrome root at commit: c6718ebbf2c677c6f63691e28c7801c563f6b19c

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.