CVE-2026-74934
Overview
Background
- `WebGLFramebuffer`
- Gecko’s object backing a WebGL framebuffer, tracking its color/depth/stencil attachments and their initialization state.
- `ResolveAttachmentData`
- A method that lazily zero-initializes any attachment slices still marked uninitialized before they can be read, so uninitialized GPU memory is never exposed.
- `fDrawBuffers` / `RefreshDrawBuffers`
- GL calls that set the framebuffer’s draw-buffer routing table;
RefreshDrawBuffersrestores the framebuffer’s real configuration after a temporary override.
Root Cause Analysis
When ResolveAttachmentData zero-initialized an uninitialized color attachment, it called gl->fClearBufferiv(LOCAL_GL_COLOR, drawBuffer, ...) (or the uiv/fv variants) using drawBuffer derived from mAttachmentPoint - LOCAL_GL_COLOR_ATTACHMENT0, but it never guaranteed that the framebuffer’s current draw-buffer mapping actually routed that index to the intended attachment. Per the GL spec, glClearBuffer*(GL_COLOR, drawBuffer, ...) clears whatever attachment slot drawBuffer maps to under the active glDrawBuffers state, so when that state mapped the index to LOCAL_GL_NONE or to a different attachment, the target attachment was left un-cleared. The invariant violated is that every uninitialized attachment slice must be fully zeroed before it becomes readable; instead the clear silently missed, leaving stale GPU memory in place.
The fix builds an explicit drawBuffersForClear vector whose drawBuffer slot is set to the real mAttachmentPoint, applies it with fDrawBuffers before clearing so the clear provably targets the intended attachment, and calls RefreshDrawBuffers() afterward to restore the framebuffer’s normal routing. This closes the gap between the assumed and actual clear target.
glClearBuffer* drawBuffer argument as if it named a color attachment when it actually indexes the mutable glDrawBuffers routing table, so initialization could be routed away from the real attachment; the fix pins the routing with an explicit fDrawBuffers call so the zeroing clear always lands on the intended attachment.Attack Path
- Set up a mismatched draw-buffer mapping
Attacker JavaScript configures a WebGL framebuffer with multiple color attachments and a
drawBuffersstate that maps the relevant index toNONEor another slot. - Leave an attachment uninitialized The page attaches or resizes a texture/renderbuffer so a color attachment slice is marked uninitialized but never explicitly cleared by content.
- Trigger lazy resolution
A read-style operation (draw,
readPixels, blit, or sampling) causesResolveAttachmentDatato run, whose clear misses the mis-routed attachment and leaves it uninitialized. - Read back stale contents
The attacker reads the now-“resolved” attachment (e.g.
readPixelsor rendering it back), retrieving whatever prior GPU memory occupied that region. - Exfiltrate cross-origin pixels Repeating the pattern lets the page harvest leftover framebuffer memory that may contain another origin’s or process’s rendered content.
Impact Assessment
Graphics: CanvasWebGL component.Changed Functions
| Function | Change | Notes |
|---|---|---|
switchdom/canvas/WebGLFramebuffer.cpp |
modified |
Files Changed
dom/canvas/WebGLFramebuffer.cpp
Audit Directions
- Lazy zero-initialization pathsReview all code that clears “uninitialized” GPU resources (framebuffers, textures, renderbuffers) to verify the clear actually reaches the resource under the current GL state, not just that a clear call was issued.
- Transient GL state overridesCheck that any temporary override of draw-buffer, viewport, or scissor state around a security-critical clear is both correctly applied beforehand and reliably restored afterward.
Patch
diff --git a/dom/canvas/WebGLFramebuffer.cpp b/dom/canvas/WebGLFramebuffer.cpp
index b07bad434c8..7afe36ab0d3 100644
--- a/dom/canvas/WebGLFramebuffer.cpp
+++ b/dom/canvas/WebGLFramebuffer.cpp
@@ -890,6 +890,11 @@ void WebGLFramebuffer::ResolveAttachmentData() const {
const uint32_t drawBuffer =
cur->mAttachmentPoint - LOCAL_GL_COLOR_ATTACHMENT0;
MOZ_ASSERT(drawBuffer <= 100);
+ std::vector<GLenum> drawBuffersForClear(drawBuffer + 1,
+ LOCAL_GL_ONE);
+ drawBuffersForClear[drawBuffer] = cur->mAttachmentPoint;
+ gl->fDrawBuffers(drawBuffersForClear.size(),
+ drawBuffersForClear.data());
switch (format->componentType) {
case webgl::ComponentType::Int:
gl->fClearBufferiv(LOCAL_GL_COLOR, drawBuffer, iZeros);
@@ -921,6 +926,7 @@ void WebGLFramebuffer::ResolveAttachmentData() const {
}
imageInfo->mUninitializedSlices.reset();
}
+ RefreshDrawBuffers();
return;
}