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

Overview: A potential heap out-of-bounds read exists in the crabbyavif library during incremental grid image decoding. A state tracking flaw allows mixing incompatible YUV formats in a grid, which interacts with an oversized buffer slice in the dav1d wrapper to bypass Rust bounds checks. This can lead to renderer heap memory being leaked into the decoded image, which an attacker could read via a <canvas> element.

Affected files:

• third_party/crabbyavif/src/src/decoder/mod.rs
• third_party/crabbyavif/src/src/codecs/dav1d.rs
• third_party/crabbyavif/src/src/image.rs

Estimated timestamp from git blame: 2025-04-11

Summary

A potential heap out-of-bounds (OOB) read vulnerability exists in the crabbyavif library when processing grid images during incremental decoding. Two separate logic flaws combine to create this issue: a validation bypass caused by state loss when resuming an incremental decode, and an oversized PointerSlice created in the dav1d codec wrapper. Together, these allow an attacker to leak adjacent heap memory from the renderer process into the decoded image pixels.

Technical Details

1. Validation Bypass in GridImageHelper

In third_party/crabbyavif/src/src/decoder/mod.rs, the decode_grid() function handles grid assembly. During incremental decoding (which is enabled for still images in Blink), if the network stalls, the function yields. When more data arrives, decode_grid() is called again.

On each call, it constructs a fresh GridImageHelper instance:

// decoder/mod.rs:1894
let mut grid_image_helper = GridImageHelper {
    // ...
    first_cell_image: None,
    // ...
};

Because first_cell_image is initialized to None on every resume, copy_from_cell_image() fails to perform consistency checks on subsequent tiles if the decode was interrupted:

// decoder/mod.rs:425
} else if self.first_cell_image.is_some()
    && !cell_image.has_same_properties_and_cicp(self.first_cell_image.unwrap_ref())
{
    return AvifError::invalid_image_grid("grid image contains mismatched tiles");
}

This bypass allows an attacker to mix tiles with different subsampling formats (e.g., a YUV 4:4:4 tile followed by a YUV 4:2:0 tile).

2. Oversized PointerSlice in dav1d Wrapper

In third_party/crabbyavif/src/src/codecs/dav1d.rs, the wrapper incorrectly uses the full image.height (the luma height) when creating PointerSlice wrappers for all planes:

// codecs/dav1d.rs:255
image.planes[plane] = Some(Pixels::from_raw_pointer(
    dav1d_picture.data[plane] as *mut u8,
    image.depth as u32,
    image.height, // ERROR: Uses luma height for chroma planes
    image.row_bytes[plane],
)?);

For YUV 4:2:0 formats, chroma buffers are half the luma height. Passing the full height creates a slice that overestimates the allocation size, defeating Rust’s runtime bounds checks.

3. Triggering the OOB Read

In third_party/crabbyavif/src/src/image.rs, copy_from_tile merges a tile into the grid. If a 1-row grid is initialized as YUV 4:4:4 (from the first tile), but a subsequent tile is YUV 4:2:0, the code calculates the copy height based on the destination grid’s height:

// image.rs:494
let src_height_to_copy = if row_index == grid.rows - 1 {
    // ...
    checked_sub!(u32_from_usize(self.height(plane))?, height_so_far)?
} 

This evaluates to the full luma height. The decoder then copies luma_height rows from the source tile’s smaller chroma buffer. Because the PointerSlice from step 2 is oversized, the Rust bounds check succeeds, and crabbyavif silently reads past the end of the dav1d allocation, copying adjacent renderer heap memory into the image.

Suggested Attacker Steps (Theoretical)

Note: These are potential steps as our tooling does not currently run live code.

1. Craft an AVIF image with a 1-row, multi-column grid.
2. Encode Tile 0 as a YUV 4:4:4 keyframe.
3. Encode Tile 1 as a YUV 4:2:0 keyframe.
4. Serve the file over HTTP with chunked encoding. Send Tile 0 data, then stall the connection to trigger an incremental decode pause in Chrome.
5. Send Tile 1 data. The decoder resumes, loses first_cell_image state, bypasses validation, and OOB-reads the Tile 1 chroma buffer.
6. Render the resulting image to an offscreen <canvas> and use getImageData() to extract the leaked heap memory.

Suggested Fix

1. Persist Grid State: Move first_cell_image out of the temporary GridImageHelper and store it in a persistent structure (e.g., Decoder or TileInfo) so format validation works across incremental decode boundaries.
2. Correct Slice Bounds: In dav1d.rs, use the appropriate plane height when creating the slice: image.height(plane.into()) instead of image.height.

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.