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 logic error in the H.265 VA-API and V4L2 hardware video decoder delegates allows non-decodable RASL frames to reside in the Decoded Picture Buffer with uninitialized GPU surfaces. Subsequent frames can reference these surfaces during inter-prediction, potentially leaking stale GPU memory contents across origins. This affects Chromium-based browsers on Linux and ChromeOS utilizing hardware-accelerated H.265 decoding.

Affected files:

• media/gpu/vaapi/h265_vaapi_video_decoder_delegate.cc
• media/gpu/v4l2/v4l2_video_decoder_delegate_h265.cc
• media/gpu/h265_decoder.cc
• media/gpu/h265_dpb.cc

Estimated timestamp from git blame: Unknown (Google3 checkout)

Summary

A potential vulnerability exists in the H.265 (HEVC) hardware video decoder implementation for VA-API and V4L2. The issue stems from how the decoder handles Random Access Skipped Leading (RASL) frames when they follow an Intra Random Access Point (IRAP) frame with the NoRaslOutputFlag set. While these RASL frames are correctly identified as non-decodable and “dropped” by the accelerator delegates, they remain in the Decoded Picture Buffer (DPB) associated with uninitialized GPU surfaces. Subsequent frames can then reference these uninitialized surfaces, leading to a cross-origin information leak of GPU memory.

Root Cause Analysis

In H265Decoder::Decode (media/gpu/h265_decoder.cc), when a new frame is encountered, a H265Picture and its corresponding GPU surface are allocated before the accelerator delegate evaluates whether the frame should be decoded.

When SubmitFrameMetadata is called in the VA-API or V4L2 delegates, the code checks if the frame is a RASL frame that should be skipped (per H.265 spec section 8.1.3). If so, the delegate sets a drop_frame_ flag and returns kOk:

// media/gpu/vaapi/h265_vaapi_video_decoder_delegate.cc
if (pic->no_rasl_output_flag_ &&
    (slice_hdr->nal_unit_type == H265NALU::RASL_N ||
     slice_hdr->nal_unit_type == H265NALU::RASL_R)) {
  drop_frame_ = true;
  return DecodeStatus::kOk;
}

Because the delegate returns success, the H265Decoder proceeds to store the picture in the DPB (media/gpu/h265_decoder.cc:1185). However, because drop_frame_ is true, the delegate subsequently skips SubmitSlice and SubmitDecode operations. Consequently, the GPU surface (typically a dmabuf allocated via GBM) is never written to by the hardware and remains uninitialized.

Chromium’s GPU surface allocation (e.g., via gbm_bo_create in media/gpu/chromeos/platform_video_frame_pool.cc) does not typically perform zero-filling. Stale data from previous allocations (possibly belonging to other origins or processes) may remain in the buffer.

Potential Exploitation Path

An attacker could potentially exploit this by providing a crafted HEVC bitstream:

1. Provide an IRAP frame that sets no_rasl_output_flag = 1.
2. Provide a RASL frame (e.g., POC 98). The decoder allocates an uninitialized surface and stores POC 98 in the DPB.
3. Provide a subsequent decodable frame (e.g., a TRAIL_R frame at POC 101) whose Reference Picture Set (RPS) includes POC 98.
4. Craft the TRAIL_R frame to use POC 98 as a reference with zero motion vectors (e.g., P-skip blocks). This causes the hardware decoder to copy the uninitialized data from the POC 98 surface into the POC 101 output surface.
5. Read the resulting pixels from POC 101 using <canvas> or the WebCodecs API to exfiltrate stale GPU heap data.

These steps are suggested based on code analysis; our current environment has not verified them with a live proof of concept.

Suggested Fix

When a frame is dropped by the delegate, the decoder should ensure the associated surface is either initialized (e.g., cleared to zero) or that the picture is marked as ‘invalid’ in the DPB so that subsequent frames cannot use it as a reference for inter-prediction.

Evaluated with Chrome root at commit: 29093e11cf509e3593f6229e4b1b075cca356049

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.