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: A structural invariant violation in Dawn’s Vulkan backend leaves a command buffer in an active render pass after an early return during command recording. By exploiting the asynchronous event polling mechanism via onSubmittedWorkDone, an attacker can bypass the ensuing DeviceLost state and force the un-gated execution of EnsureCommandsFlushed(). This submits invalid Vulkan commands (vkCmdPipelineBarrier and vkEndCommandBuffer) into the active render pass, leading to undefined behavior and a potential memory corruption primitive in the unsandboxed GPU process.

Affected files:

• third_party/dawn/src/dawn/native/vulkan/CommandBufferVk.cpp
• third_party/dawn/src/dawn/native/vulkan/CommandBufferVk.h
• third_party/dawn/src/dawn/native/vulkan/QueueVk.cpp
• third_party/dawn/src/dawn/native/Device.cpp
• third_party/dawn/src/dawn/native/Queue.cpp

Estimated timestamp from git blame: 2026-04-01

1. Summary of the Issue (Meant for Human Triage)

A structural state desynchronization vulnerability exists in Dawn’s Vulkan backend during render pass command recording. Within CommandBuffer::RecordRenderPass, RecordBeginRenderPass and RecordEndRenderPass are invoked without RAII or scoped guards. If a DAWN_TRY or DAWN_TRY_ASSIGN macro triggers an early return after the render pass has begun—for instance, due to an out-of-memory (OOM) error during specialized descriptor set allocation for external Android textures—the render pass is never explicitly ended. This leaves the persistent Queue::mRecordingContext command buffer structurally malformed within an active Vulkan render pass.

While Dawn’s downstream defense-in-depth typically catches the unexpected internal error, promotes it to DeviceLost, and gates further queue submissions, an attacker-reachable bypass exists via Dawn’s asynchronous event polling mechanism (EventManager). By registering a queue.onSubmittedWorkDone() event when pending commands exist, the event is tracked against an unsubmitted serial. Following the early-return and DeviceLost promotion, ProcessPollEvents will poll the tracked event. Because the event is not ready, it invokes EnsureCommandsFlushed(), which crucially lacks an IsLost() guard. This blindly executes SubmitPendingCommandsImpl(), emitting vkCmdPipelineBarrier and vkEndCommandBuffer into the active render pass.

This violates core Vulkan specification invariants (VUID-vkCmdPipelineBarrier-None-09553 and VUID-vkEndCommandBuffer-commandBuffer-00060). Because the GPU process is unsandboxed on Android and the malformed VkCommandBuffer triggers driver-level undefined behavior, this flaw constitutes a potential High (S1) sandbox escape / GPU memory corruption primitive.

2. Proof-of-Concept & Detailed Execution Flow

The following is a step-by-step trace of how an attacker can trigger this vulnerability (note: these are potential steps mapped directly to validated code paths):

Phase 1: Setup & Event Registration

1. External Texture Import: The attacker uses device.importExternalTexture({source: videoElement}) on Android to import an AHardwareBuffer-backed video frame (Feature::OpaqueYCbCrAndroidForExternalTexture).
2. Pipeline Creation: The attacker creates a GPURenderPipeline bound to this external texture, causing RenderPipelineVk::InitializeImpl to set mRequiresSpecialization = true (third_party/dawn/src/dawn/native/vulkan/RenderPipelineVk.cpp:400-403).
3. Pending Commands Activation: The attacker executes a minor GPU operation (e.g., a buffer creation that triggers a lazy clear) to ensure Queue::HasPendingCommands() returns true (i.e., mRecordingContext.needsSubmit = true).
4. Event Tracking: The attacker calls device.queue.onSubmittedWorkDone(). QueueBase::APIOnSubmittedWorkDone handles this (Queue.cpp:181). Because HasPendingCommands() is true, GetScheduledWorkDoneSerial() (ExecutionQueue.cpp:393-395) returns the pending command serial (GetLastSubmittedCommandSerial() + 1). An event is registered in EventManager waiting on this future serial.

Phase 2: Error Injection & Invariant Violation 5. Resource Exhaustion: The attacker intentionally exhausts Vulkan descriptor pools or device memory by allocating many large GPU buffers and distinct external-texture bind groups. 6. Command Recording: The attacker records a primary render pass (beginRenderPass, setPipeline, draw, endRenderPass) and submits it: device.queue.submit([commandBuffer]). 7. Vulkan Render Pass Started: During Queue::SubmitImpl (QueueVk.cpp:102), commands are translated. CommandBuffer::RecordRenderPass emits vkCmdBeginRenderPass into the active command buffer (CommandBufferVk.cpp:1748). 8. OOM Failure Triggered: Processing the Draw command invokes state.SyncAndRun (CommandBufferVk.cpp:1799). Since mRequiresSpecialization == true, it branches to RunWithSpecialization. Due to the attacker’s prior resource exhaustion, vkAllocateDescriptorSets fails, returning VK_ERROR_OUT_OF_DEVICE_MEMORY. 9. Early Return (The Bug): Dawn’s CheckVkSuccessImpl converts this to DAWN_INTERNAL_ERROR (InternalErrorType::Internal). The DAWN_TRY_ASSIGN macro causes an immediate early return from RunWithSpecialization and RecordRenderPass, completely skipping the required RecordEndRenderPass call (CommandBufferVk.cpp:2036). 10. State Leakage: Queue::SubmitImpl also early-returns, bypassing DAWN_TRY(SubmitPendingCommandsImpl()) (QueueVk.cpp:110). The absl::Cleanup block that resets the context is skipped, leaking the active render pass state inside mRecordingContext (with needsSubmit = true).

Phase 3: Escalation via Un-gated Event Polling 11. Device Lost Promotion: QueueBase::APISubmit consumes the error (Queue.cpp:177). DeviceBase::ConsumeError identifies InternalErrorType::Internal, concludes the backend cannot recover, and promotes it to DeviceLost (Device.cpp:689), transitioning the device to State::BeingDisconnected. 12. Event Polling: InstanceBase::ProcessEvents() eventually calls EventManager::ProcessPollEvents() (EventManager.cpp:223). 13. Bypassing the Guard: The WorkDoneEvent from Step 4 evaluates IsReadyToComplete(). Since the pending serial was never submitted (due to the early return), waitSerial > GetLastSubmittedCommandSerial() remains true. The event is not ready. 14. Flushing Commands: ProcessPollEvents calls WaitQueueSerials (EventManager.cpp:256), which calls queue->WaitForQueueSerial. Because waitSerial > GetLastSubmittedCommandSerial(), it invokes DAWN_TRY(EnsureCommandsFlushed(waitSerial)) (ExecutionQueue.cpp:106). 15. Undefined Behavior Reached: EnsureCommandsFlushed (ExecutionQueue.cpp:330-338) lacks an IsLost() check. It unconditionally calls SubmitPendingCommands(), invoking SubmitPendingCommandsImpl() (QueueVk.cpp:296). 16. Invalid Vulkan Emission: Because mRecordingContext.needsSubmit is still true, SubmitPendingCommandsImpl processes the leaked context. It calls Buffer::TransitionMappableBuffersEagerly (emitting vkCmdPipelineBarrier) and directly invokes vkEndCommandBuffer (QueueVk.cpp:321). Emitting these commands while a render pass is active violates Vulkan specs and triggers driver-level undefined behavior/crashes.

Suggested Fix:

• Ensure CommandBuffer::RecordRenderPass utilizes an RAII wrapper (e.g., absl::Cleanup within RenderPassState) to guarantee vkCmdEndRenderPass is always invoked, even on DAWN_TRY early returns.
• Add an IsLost() guard to ExecutionQueueBase::EnsureCommandsFlushed and SubmitPendingCommands to prevent the submission of stale pending commands after device loss.
• Ensure mRecordingContext is explicitly reset if Queue::SubmitImpl returns early due to an error.

3. Technical Verification Details (Automated Audit Logs - Reviewers may skip this section)

Prior Critic Verdict:

*   **Severity:** Low (S3)
*   **Brief Notes / Reasoning:**
    Rated Low (S3) per severity guidelines for GPU invariant violations caught by defense-in-depth. The DAWN_TRY early returns inside CommandBuffer::RecordRenderPass structurally violate the §G3 invariant by leaving a VkCommandBuffer with an active render pass. An attacker-reachable path via Vulkan descriptor pool exhaustion (VK_ERROR_OUT_OF_DEVICE_MEMORY) exists on Android. However, the resulting DAWN_INTERNAL_ERROR is promoted to DeviceLost at Device.cpp:670-687, preventing any spec-invalid vk* calls. Not an S4 because an attacker-reachable path was demonstrated, but capped at S3 because the observed consequence is a clean device-lost.

Validator Double-Check & Escalation Confirmation: The prior Critic verdict was re-evaluated against the codebase using exhaustive traces. While the initial determination correctly identified the structural invariant violation and the DeviceLost promotion (capping the severity at S3 for the primary execution paths), further code-reachability proofs confirmed an un-gated asynchronous escalation path that successfully reaches the GPU driver sink.

• ProcessPollEvents to EnsureCommandsFlushed Trace:

  • Verified EventManager.cpp:223-256: ProcessPollEvents processes mEventState.events. Non-ready events are added to queueWaitSerialMaps and passed to WaitQueueSerials(..., Nanoseconds(0u)).
  • Verified ExecutionQueue.cpp:88-149: WaitForQueueSerial executes. Under both thread-safe and non-thread-safe toggles, if waitSerial > GetLastSubmittedCommandSerial(), it acquires the device guard and calls DAWN_TRY(EnsureCommandsFlushed(waitSerial)).
  • Verified ExecutionQueue.cpp:330-338: EnsureCommandsFlushed validates serial > GetLastSubmittedCommandSerial() and blindly calls SubmitPendingCommands() (which invokes SubmitPendingCommandsImpl()). Crucially, there is no IsLost() check in EnsureCommandsFlushed.

• Serial State Desync Confirmation:

  • Verified Queue.cpp:181-250: APIOnSubmittedWorkDone registers an event. If HasPendingCommands() is true, the waitSerial is GetScheduledWorkDoneSerial() (GetLastSubmittedCommandSerial() + 1).
  • Verified Device.cpp:649-725: AssumeCommandsComplete() is not called during HandleDeviceLost or HandleError. The stale recording context genuinely persists until Destroy()/WaitForIdleForDestruction.
  • Verified Queue.cpp:303-311: QueueBase::HandleDeviceLoss clears mTasksInFlight and shifts tasks to CallbackTaskManager, but does not resolve the TrackedEvents within EventManager.
  • Therefore, an aborted queue submission leaves waitSerial > GetLastSubmittedCommandSerial() true, bypassing IsReadyToComplete() checks and ensuring the event is processed by WaitQueueSerials.

• Sink Validation:

  • Verified QueueVk.cpp:296-321: SubmitPendingCommandsImpl executes. mRecordingContext.needsSubmit remains true due to the early-return in Queue::SubmitImpl. The method unconditionally executes vkCmdPipelineBarrier and vkEndCommandBuffer(mRecordingContext.commandBuffer).
  • Conclusion: The spec-invalid commands are deterministically passed to the Vulkan driver, upgrading the consequence from a clean DeviceLost to driver-level undefined behavior. Since the GPU process on Android is unsandboxed, this represents a potential High (S1) issue.

Evaluated with Chrome root at commit: b96d2ec58f4f5f92b540a723966b199d6e9951b4

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.