Flapjack (go/flapjack), an LLM-powered static analysis tool, has identified the following potential security issue.

Overview: The Vp8Parser fails to validate that the size of the compressed frame header does not exceed the first_part_size declared in the VP8 frame tag. This causes an integer underflow when calculating the control partition size for VA-API and V4L2 hardware decoders. The massive underflowed size is passed to GPU drivers and potentially the kernel, leading to out-of-bounds memory access, information leaks, or GPU process RCE.

Affected files:

• media/parsers/vp8_parser.cc
• media/gpu/vaapi/vaapi_utils.cc
• media/gpu/v4l2/v4l2_video_decoder_delegate_vp8.cc
• media/gpu/vaapi/test/vp8_decoder.cc

Estimated timestamp from git blame: 2021-11-09

Summary

A potential integer underflow leading to an out-of-bounds read/write was identified in Chromium’s VP8 video decoding utility. The root cause is a lack of validation in media::Vp8Parser::ParseFrameHeader (media/parsers/vp8_parser.cc), which fails to ensure that the number of bits consumed when reading the compressed frame header does not exceed the first_part_size specified in the uncompressed VP8 frame tag.

Technical Details

1. Parsing Frame Tag: In media/parsers/vp8_parser.cc, the Vp8Parser::ParseFrameTag method extracts the first_part_size from the VP8 frame tag (a 19-bit value). An attacker can craft a frame tag where this value is arbitrarily small (e.g., 5).
2. Parsing Compressed Header: Subsequently, Vp8Parser::ParseFrameHeader uses a Vp8BoolDecoder to parse the compressed header. Crucially, the decoder is initialized with the entire remaining frame buffer (bytes_left_), not just the first_part_size bytes. The number of bits consumed during this process is stored in fhdr->macroblock_bit_offset.
3. Missing Validation: The parser successfully returns without verifying that the bytes consumed for the compressed header ((macroblock_bit_offset + 7) / 8) actually fit within the first_part_size.
4. The Underflow: In multiple hardware video decoder delegates, such as media/gpu/vaapi/vaapi_utils.cc (and similarly in media/gpu/vaapi/test/vp8_decoder.cc), the size of the first partition’s macroblock data is calculated by subtracting the header size from first_part_size:

   slice_param->partition_size[0] =
       frame_header.first_part_size -
       ((frame_header.macroblock_bit_offset + 7) / 8);
   

   If the attacker-controlled first_part_size (e.g., 5) is smaller than the consumed header size in bytes (e.g., 13), an unsigned integer underflow occurs. Since partition_size[0] is an unsigned 32-bit integer (uint32_t in the VA-API VASliceParameterBufferVP8 struct), it wraps around to an extremely large value (e.g., 0xFFFFFFF8).

Impact

• GPU Information Leak / ASLR Bypass: This massive size is passed directly to the VA-API hardware/driver via vaapi_wrapper_->MapAndCopyAndExecute in the privileged GPU process. The hardware may read massively beyond the end of the provided bitstream buffer. If the driver or hardware interprets this out-of-bounds data as macroblock data and incorporates it into the decoded frame, a cross-origin attacker could render the video to a canvas, extract the pixels, and read arbitrary GPU memory contents.
• Remote Code Execution (RCE): If the specific VA-API driver implementation (e.g., Intel media driver, Mesa) performs internal buffer allocations or memory copies (memcpy) based on this massive partition size before hardware submission, it will result in a heap buffer overflow and arbitrary code execution within the GPU process.
• Potential Kernel Sandbox Escape: On V4L2-based platforms (e.g., ChromeOS on ARM), these unvalidated values are copied into a v4l2_ctrl_vp8_frame structure and passed directly to the kernel via ioctl in media/gpu/v4l2/v4l2_video_decoder_delegate_vp8.cc. If the kernel driver performs the same subtraction without underflow validation, it could result in a kernel-level out-of-bounds read/write and a full sandbox escape.

Potential Steps to Reproduce

Note: These are potential steps as a full Proof of Concept (PoC) has not yet been executed.

1. Craft a WebM media file containing a VP8 video track.
2. Modify a single VP8 keyframe in the bitstream.
3. Set the first_part_size field in the uncompressed frame tag to a very small value (e.g., 5).
4. Ensure the subsequent compressed frame header contains valid boolean entropy data that consumes more bytes than the first_part_size (e.g., > 40 bits).
5. Serve this malicious WebM file via an HTML5 <video> element on an attacker-controlled webpage.
6. When the victim visits the page on a device supporting VA-API or V4L2 hardware decoding, the Chromium media pipeline will parse the frame without error and pass the underflowed size to the GPU driver/kernel.

Evaluated with Chrome root at commit: 9760e6c70cd33a320713361f17c6dcca85648c0f

Results from Flapjack so far have been promising, but it can be wrong in its deductions. At this time, it does not produce proof of concepts or fuzzer tests. If this proves to be a false positive, please close as WAI; data from false positives will be used to improve Flapjack’s accuracy over time. And please feel free to reach out to me directly if you have concerns or feedback on the project.