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

Overview: The D3D12 AV1 video encoding delegate fails to validate reference buffer indices provided by an untrusted renderer before passing them to the hardware driver. By supplying out-of-bounds indices, a compromised renderer can trigger an out-of-bounds array access within the D3D12 GPU driver. This driver-level memory corruption could potentially lead to a sandbox escape from the Renderer to the GPU process.

Affected files:

• media/gpu/windows/d3d12_video_encode_av1_delegate.cc
• media/gpu/windows/d3d12_video_encode_delegate.cc

Estimated timestamp from git blame: 2025-12-17

Summary

A vulnerability exists in the D3D12 AV1 video encoding implementation in Chrome (media/gpu/windows/d3d12_video_encode_av1_delegate.cc). When manual reference buffer control is enabled, the delegate processes reference indices supplied by the renderer via Mojo (VideoEncoder::EncodeOptions::reference_buffers). While Chrome correctly validates the number of reference buffers, it completely fails to validate the values of the indices themselves before passing them to the underlying Independent Hardware Vendor (IHV) D3D12 driver.

According to the D3D12 AV1 specification, reference indices must strictly point to valid Decoded Picture Buffer (DPB) slots, which range from 0 to 7. Because the values from the untrusted renderer (which can be up to 255) are copied directly into the driver’s command struct without bounds checking, an attacker can reliably trigger an out-of-bounds array access within the third-party GPU driver.

Technical Details

1. Mojo IPC: A compromised renderer acquires a media.mojom.VideoEncodeAccelerator interface. It calls Encode(), passing a media.mojom.VideoEncodeOptions struct. The renderer populates the reference_buffers array with an out-of-bounds index (e.g., [200]) and crucially leaves the optional update_buffer field empty.
2. Size Validation Passes: In the GPU process, D3D12VideoEncodeDelegate::Encode (media/gpu/windows/d3d12_video_encode_delegate.cc:276) correctly checks that the size of the reference_buffers array does not exceed the maximum allowed (typically 8 for AV1). This check passes since the array size is only 1.
3. Missing Value Validation: The execution flow reaches D3D12VideoEncodeAV1Delegate::HandleManualReferences (media/gpu/windows/d3d12_video_encode_av1_delegate.cc:1449). This function copies the unvalidated index (200) directly into the picture_params_ struct, which is mapped directly to the D3D12 API’s D3D12_VIDEO_ENCODER_AV1_PICTURE_CONTROL_CODEC_DATA.

   // Set primary reference frame to the first reference buffer index.
   picture_params_.PrimaryRefFrame = options.reference_buffers[0];
   
   // ... we pad the remaining ReferenceIndices[] with `options.reference_buffers[0]` ...
   for (size_t i = 0; i < 7ull; i++) {
     base::span(picture_params_.ReferenceIndices)[i] =
         options.reference_buffers.size() > i ? options.reference_buffers[i]
                                              : options.reference_buffers[0];
   }
   

4. Driver Invocation: The picture_params_ struct is subsequently passed to the D3D12 driver via ID3D12VideoEncodeCommandList::EncodeFrame. The driver expects these indices to be within [0, 7]. By providing 200, the driver performs an out-of-bounds read/write on its internal DPB tracking arrays.
5. Bypassing Chrome Safety Checks: Later in Chrome’s execution flow, D3D12VideoEncodeAV1Delegate::RefreshDPBAndDescriptors() is called. Because the attacker deliberately omitted options.update_buffer, picture_params_.RefreshFrameFlags was evaluated to 0 in step 3.

   void D3D12VideoEncodeAV1Delegate::RefreshDPBAndDescriptors() {
     // ...
     if (picture_params_.RefreshFrameFlags == 0) {
       return; // Early exit cleanly bypasses the CHECK below.
     }
     uint8_t refreshed_dpb_idx = std::countr_zero((picture_params_.RefreshFrameFlags));
     CHECK_LT(refreshed_dpb_idx, max_num_ref_frames_);
     // ...
   }
   

   This early return elegantly bypasses a CHECK_LT assertion that would have otherwise safely crashed the GPU process on invalid inputs, ensuring the driver-level exploit executes cleanly.

Potential Impact

The impact depends on the specific hardware driver implementation (e.g., Intel, AMD, NVIDIA). At minimum, this results in a GPU process crash. However, memory corruption at the driver level could potentially be exploited to achieve arbitrary code execution within the highly privileged GPU process, representing a full sandbox escape from the Renderer.

(Note: These are potential steps based on source code analysis; our tooling has not executed a live proof-of-concept.)

Suggested Fix

In D3D12VideoEncodeAV1Delegate::HandleManualReferences (or centrally in D3D12VideoEncodeDelegate::Encode), validate that every element within the options.reference_buffers array is strictly less than the maximum allowed number of reference frames (GetMaxNumOfManualRefBuffers()).

// In D3D12VideoEncodeAV1Delegate::HandleManualReferences:
for (uint8_t ref_idx : options.reference_buffers) {
  if (ref_idx >= GetMaxNumOfManualRefBuffers()) {
    // Return an error or crash cleanly.
    return;
  }
}

(Note: The H.265 delegate already performs a similar validation check via reference_frame_manager_.GetReferenceFrameId(reference_buffers[i]).)

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.