image-rs / image-webp Goto Github PK

Found with the fuzzer. Several test cases that take over 60s to decode, ranging from ~90 to ~400 bytes: webp_slow_to_decode.tar.gz

Tested on commit cc5ec05

I noticed that all of the lossy reference images had even dimensions. I wasn't sure what the process was for adding new test images.

I wrote code that incorrectly handled some end pixels in rows but passed all the tests. I created these two tests to check that my function matched the current fill_single implementation. The 3x3 test is what my code failed at first since I was handling 2 pixels at a time due to the chroma plane.
okaneco@0f96c2e

We should add fuzz testing to detect any inputs that cause the decoder to crash

In image-rs/image#1872, @Shnatsel identified WebP images decoded improperly. We should test those images again and root-cause any differences found. If licenses are compatible, it would also be nice to add some of those images to our test suite

Found by the decode_animated fuzzer. File to reproduce: crash-35139c183ff06d385a03fd81ae53e43959eabf81.webp.gz

thread '<unnamed>' panicked at image-webp/src/decoder.rs:701:12:
attempt to add with overflow

Tested on commit d4bb3b3

We should audit the decoder to ensure it is properly enforcing memory limits.

This file triggers a panic: crash-f1196f2973d6d813017f35c48b478c2623063c99.webp.gz

thread '<unnamed>' panicked at image-webp/src/decoder.rs:592:84:
index out of bounds: the len is 191 but the index is 191

This makes me want to set up a script to automatically file fuzzing crashes to the bug tracker

Found by the decode_still fuzzer. Testcase:

crash-6e515dd2b891121ce5a51385c0730f4a21bf2efe.webp.gz

thread '<unnamed>' panicked at image-webp/src/huffman.rs:95:21:
attempt to add with overflow

Tested on commit c7b77cb

It seems YUV to RGB conversion is now the bottleneck, accounting for 45% of the time.

Profile showing it: https://share.firefox.dev/46lRpxt

Test image: test_lossy.webp.gz

Measured on commit 18867ec

Code used:

use std::error::Error;

fn main() -> Result<(), Box<dyn Error>> {
    let input = std::env::args().nth(1).unwrap();
    let f = std::fs::File::open(input)?;
    let reader = std::io::BufReader::new(f);
    let mut decoder = webp::WebPDecoder::new(reader)?;
    let mut output = vec![0u8; decoder.output_buffer_size()];
    let _img = decoder.read_image(&mut output)?;
    Ok(())
}

It seems that the AFL seeds for the WebP format are overly tuned to the libwebp implementation, and are not a good starting point for fuzzing other decoders.

When seeded with the smallest real-world images that I scraped from the web, the fuzzer still finds panics almost instantly:
smallest_scraped_webp.tar.gz

Sample image triggering a panic: crash-70d04adad08d65334cc6e947843ae382420aef78.webp.gz
which causes

thread '<unnamed>' panicked at image-webp/src/vp8.rs:851:14:
chunk size must be non-zero

The current fuzz harness, decode_still, only decodes the first frame of the image. It would be great to fuzz decoding of animated images as well.