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 without the Chrome Security team. Please see https://chromium.googlesource.com/chromium/src/+/main/docs/security/ai-generated-security-bugs-faq.md for more information.

Overview: In VaapiWrapper::UploadVideoFrameToSurface, a VAImage struct is allocated on the stack without zero-initialization. If vaDeriveImage fails with an unexpected error code, the code proceeds to use the uninitialized struct. This could potentially allow a compromised renderer to achieve a cross-context Use-After-Free or Out-of-Bounds write in the GPU process by grooming the stack.

Affected files:

• media/gpu/vaapi/vaapi_wrapper.cc

Estimated timestamp from git blame: 2019-04-03

Root Cause

In media/gpu/vaapi/vaapi_wrapper.cc, the function VaapiWrapper::UploadVideoFrameToSurface allocates a VAImage struct on the stack without initializing it:

// media/gpu/vaapi/vaapi_wrapper.cc:2849
VAImage image;
VAStatus va_res = vaDeriveImage(va_display_, va_surface_id, &image);
if (va_res == VA_STATUS_ERROR_OPERATION_FAILED) {
  // Fallback path that initializes the image
  ...
}

The libva frontend implementation of vaDeriveImage does not initialize the output struct if it returns an error. The error handling in UploadVideoFrameToSurface only checks for VA_STATUS_ERROR_OPERATION_FAILED. If vaDeriveImage returns any other error code (e.g., VA_STATUS_ERROR_ALLOCATION_FAILED), the fallback path is skipped, and the image struct remains filled with stack residue.

Impact

1. Cross-Context Use-After-Free (UAF)

An absl::Cleanup block captures the uninitialized image reference:

// media/gpu/vaapi/vaapi_wrapper.cc:2863
absl::Cleanup vaimage_deleter = [this, &image]() {
  DestroyVAImage(va_display_, image);
};

DestroyVAImage checks if image.image_id != VA_INVALID_ID and calls vaDestroyImage. If an attacker can control the stack residue, they can supply a valid image_id that is currently actively used by another context within the shared VADisplay in the GPU process. This prematurely destroys the image, leading to a UAF when the rightful owner accesses it.

2. Cross-Context / Out-of-Bounds (OOB) Write

If the stack residue coincidentally (or intentionally) bypasses subsequent validation checks (e.g., image.format.fourcc == VA_FOURCC_NV12 and dimension checks), the code maps the buffer specified by the uninitialized image.buf:

// media/gpu/vaapi/vaapi_wrapper.cc:2885
auto mapping = ScopedVABufferMapping::Create(..., va_display_, image.buf);
...
ret = libyuv::I420ToNV12(..., UNSAFE_TODO(image_ptr + image.offsets[0]), image.pitches[0], ...);

If image.buf points to a buffer owned by another context, and offsets/pitches are derived from stack garbage, this allows copying attacker-controlled video frame data to an attacker-controlled offset within that buffer, resulting in a cross-context OOB write.

Potential Exploit Steps

Note: These are potential steps; our tooling has not executed a proof-of-concept.

1. A compromised Renderer process connects to the GPU process via the media::mojom::VideoEncodeAccelerator interface.
2. The attacker calls Initialize with kShmem storage type.
3. The attacker issues highly deterministic IPC calls that execute on the GPU process’s dedicated encoder thread to groom the stack memory. The goal is to place specific values (e.g., a target image_id, VA_FOURCC_NV12, and a target buf ID) at the exact offset where the VAImage struct will be allocated.
4. The attacker intentionally exhausts driver resources or provides invalid parameters to ensure vaDeriveImage fails with an error like VA_STATUS_ERROR_ALLOCATION_FAILED.
5. The attacker calls Encode() with a shared memory video frame, triggering UploadVideoFrameToSurface. The uninitialized struct causes the OOB write and subsequent cross-context UAF upon function exit.

Proposed Fix

1. Zero-initialize the struct upon declaration: VAImage image = {};
2. Safely handle unexpected failure modes from vaDeriveImage. If va_res is neither VA_STATUS_SUCCESS nor VA_STATUS_ERROR_OPERATION_FAILED, the function should log the error and return false early, avoiding the use of the image struct.

Evaluated with Chrome root at commit: a1e33f5848218e21d4a16ae2c1bc94e815c30c7f

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