10596a9178664dc42b7f3daf9113d0bfc89701eb [M144] Validate framebufferTextureMultiviewOVR target, attachment
The bug at a glance
The OVR_multiview2 framebufferTextureMultiviewOVR entry point passed the WebGL target and attachment enums through without validation; the commit message states an out-of-range value could lead to resource-tracking issues inside the WebGL framebuffer bookkeeping, a bounded integrity concern rather than a clear memory-corruption primitive, so medium.
An attacker running ordinary WebGL2 content can pass bogus target/attachment enums to framebufferTextureMultiviewOVR to desynchronize the renderer’s framebuffer attachment tracking, which is the kind of state confusion that feeds later WebGL exploits.
Root cause
framebufferTextureMultiviewOVR validated the texture layer, texture target and level, but never validated the framebuffer binding target and the attachment point. The patch inserts a ValidateFramebufferFuncParameters call that reuses the same checks framebufferTexture2D performs, rejecting out-of-range target/attachment combinations before the attachment is recorded. Without it, an unexpected enum reached the attachment-tracking code with no guarantee it was a valid framebuffer slot.
Key code
Added target/attachment validation reused from framebufferTexture2D
if (!static_cast<WebGL2RenderingContextBase*>(scoped.Context())
->ValidateFramebufferFuncParameters(
"framebufferTextureMultiviewOVR", target, attachment)) {
return;
}
Patch walkthrough
third_party/blink/renderer/modules/webgl/ovr_multiview_2.cc— Adds a ValidateFramebufferFuncParameters guard so the framebuffer target and attachment enum are validated the same way framebufferTexture2D validates them, preventing an out-of-range value from reaching framebuffer attachment tracking.
Background
OVR_multiview2 / framebufferTextureMultiviewOVR — A WebGL2 extension method that attaches a range of texture-array layers to a framebuffer attachment for multiview rendering.
ValidateFramebufferFuncParameters — Blink’s shared WebGL check that the framebuffer target and attachment point enums are legal before an attachment is bound.
Vulnerability window
- Reachability — Reachable from ordinary web content in a stock build via a WebGL2 context with the OVR_multiview2 extension enabled; no flag or special permission required.
- Trigger — Script calls framebufferTextureMultiviewOVR with an out-of-range target or attachment enum.
- Primitive — Pre-patch the unvalidated enum reaches framebuffer attachment tracking, corrupting resource-tracking state (inferred).
- Escalation — Confused framebuffer/attachment state could be leveraged toward further WebGL memory issues (inferred).
Proof of concept
Conceptually: obtain a WebGL2 context, enable OVR_multiview2, create a texture array and framebuffer, then call framebufferTextureMultiviewOVR passing an invalid framebuffer target or attachment enum and observe that pre-patch it is accepted without validation.
Exploitation
- Setup — Create a WebGL2 context and enable the OVR_multiview2 extension.
- Trigger — Invoke framebufferTextureMultiviewOVR with an out-of-range target/attachment to desynchronize attachment tracking (inferred).
- Leverage — Chain the inconsistent framebuffer state with other WebGL operations to reach a corruption primitive (inferred).
Detection & hunting
For defenders and detection engineers:
- grep for framebufferTextureMultiviewOVR / framebufferTextureMultisampleMultiviewOVR implementations — Check each multiview framebuffer entry point calls ValidateFramebufferFuncParameters on target and attachment before recording the attachment.
- WebGL INVALID_ENUM / INVALID_OPERATION telemetry on multiview calls — Spikes of multiview framebuffer calls with unusual enums can indicate probing.
Audit directions
- Other WebGL/WebGL2 framebuffer-attachment entry points in blink/renderer/modules/webgl — Audit every framebufferTexture* variant (multisample, multiview, layer) to confirm target and attachment are validated consistently with framebufferTexture2D.