Fuzzing lewton goes through the "vorbis inside ogg" codepath, which verifies CRC32 checksum on the input. This seems to prevent any kind of meaningful fuzzing.

I have disabled CRC32 checks in ogg crate during fuzzing (using conditional compilation as described in honggfuzz-rs readme) and immediately got panics on out-of-bounds access to a slice. It seems that because of CRC32 lewton was never really fuzzed.

Steps to reproduce the crash: git clone https://github.com/Shnatsel/lewton-fuzz,
download files http://rpg.hamsterrepublic.com/ohrrpgce/File:Slash8-Bit.ogg and https://commons.wikimedia.org/wiki/File:Example.ogg put them in honggfuzz input directory, run
cargo hfuzz run lewton-fuzz

I had to separate the lewton fuzz target into its own repo because I'm on stable and this repo requires nightly to build. The Cargo.toml files in its repo is repointed to the patched lewton crate that refers to patched ogg crate that doesn't perform CRC32 check in fuzzing mode. I also had to drop all .unwrap()s in the fuzz target code because they were causing panics that were false positives (duh). I'm not sure why they were there in the first place.

This problem with checksums is likely not exclusive to lewton; most multimedia formats employ checksums of some description, and this prevents unmodified libraries from being fuzzed. This needs to be verified for every fuzz target.