Project Fortify, an experimental security project, has identified the following potential security issue.

Overview: Dawn’s BlitTextureToBuffer prematurely marks destination buffers as initialized before performing fallible internal operations like memory allocation. If an allocation fails (e.g., OOM) and the CommandEncoder is abandoned, the error is silently discarded while the buffer remains marked as initialized, bypassing LazyClearResourceOnFirstUse and allowing an attacker to map uninitialized GPU memory.

Affected files:

• third_party/dawn/src/dawn/native/BlitTextureToBuffer.cpp
• third_party/dawn/src/dawn/native/Buffer.cpp
• third_party/dawn/src/dawn/native/EncodingContext.cpp

Estimated timestamp from git blame: 2024-07-02

Description

In third_party/dawn/src/dawn/native/BlitTextureToBuffer.cpp, the BlitTextureToBuffer function is used as a workaround for certain texture-to-buffer copies on backends like OpenGL, GLES, and D3D11. This function prematurely updates the initialized state of the destination buffer before performing fallible internal operations.

At line 1167 in BlitTextureToBuffer.cpp:

dst.buffer->SetInitialized(fullSizeCopy || dst.buffer->IsInitialized());

If fullSizeCopy is true (meaning the copy operation is expected to overwrite the entire buffer), the destination buffer is immediately marked as initialized.

Following this, several internal operations occur that can fail, most notably device->CreateBuffer (e.g., at lines 1199 and 1253) which may fail with an Out Of Memory (OOM) error if GPU memory is exhausted. When such an error occurs, the DAWN_TRY or DAWN_TRY_ASSIGN macros cause the function to return early. In the context of a CommandEncoder, this error is deferred into the EncodingContext.

If the attacker then releases the CommandEncoder without calling finish(), the deferred error is silently discarded during EncodingContext::Destroy(). No device-lost event occurs, and the destination buffer remains in the incorrectly marked ‘initialized’ state.

Because the recording of the BlitTextureToBuffer commands was aborted, the destination buffer’s contents are never actually updated or cleared. However, since the buffer is marked as initialized, subsequent operations (such as MapAsync or using the buffer as a source in another copy) will evaluate NeedsInitialization() as false. This skips the LazyClearResourceOnFirstUse step (verified in Buffer.cpp), which is intended to zero-initialize buffers before their first use. This allows an attacker to read uninitialized GPU memory, potentially containing sensitive data from other WebGPU contexts or previous allocations in the same GPU process.

Note: This analysis relies on source code review. The steps below outline a potential exploit strategy but have not been verified with a live Proof of Concept.

Potential Reproduction Steps

1. Use a WebGPU-enabled browser on a platform using the OpenGLES or D3D11 backend.
2. Create a GPUBuffer (B) with COPY_DST | MAP_READ usage and a size matching a planned copy.
3. Create a GPUTexture (T) with a format that triggers a blit workaround (e.g., depth16unorm on GLES).
4. Induce GPU memory pressure to ensure internal allocations fail (e.g., by allocating many large buffers until near the driver limit).
5. Use a GPUCommandEncoder to call copyTextureToBuffer({texture: T}, {buffer: B}, ...) such that it covers the full buffer (fullSizeCopy becomes true).
6. Internal CreateBuffer calls within BlitTextureToBuffer fail due to OOM. The error is deferred in the encoder’s EncodingContext.
7. Destroy/Release the GPUCommandEncoder without calling finish(). The deferred error is silently dropped during EncodingContext::Destroy().
8. Release the pressure buffers from step 4.
9. Call B.mapAsync(GPUMapMode.READ) and read the buffer’s contents via getMappedRange(). The contents will be uninitialized GPU memory instead of zeros, as LazyClearResourceOnFirstUse is bypassed.

Suggested Fix

Ensure that the destination buffer is only marked as initialized after all fallible operations in BlitTextureToBuffer have succeeded, or defer the SetInitialized(true) call until the command is actually submitted or executed. Alternatively, track whether the initialization was performed by a specific command and revert the state if the command fails to encode or is discarded.

Evaluated with Chrome root at commit: a9cbf6e8b275fe4147435aa905f3b7f5a656f5f0

Results from 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.