You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Given a crafted input, lewton allocates over 1500 Mb of physical memory and spends ~6 seconds decoding a tiny 18kb file. This issue can be used to cause denial of service.
Steps to reproduce: RUSTFLAGS='--cfg=fuzzing' cargo run --release --example perf /path/to/malformed/file.ogg
Here's a more egregious 14kb sample that takes 30 seconds and 5Gb of actually used memory to decode: tiny-5gb-30sec-input.ogg.zip
It should be possible to synthesize files causing even more dramatic load, but fuzzer normally doesn't do this because spending 30 seconds per execution would be impractically slow.
Callgrind is telling me that most time is spent in lookup_vec_val_decode. Printing out codebook_entries and codebook_dimensions gives me really large values for both testcases if you multiply the two numbers together (1 364 875 785 for one sample, 376 286 472 for the other).
This is basically one of those "finding a reasonable limit" cases.
Given a crafted input, lewton allocates over 1500 Mb of physical memory and spends ~6 seconds decoding a tiny 18kb file. This issue can be used to cause denial of service.
Steps to reproduce:
RUSTFLAGS='--cfg=fuzzing' cargo run --release --example perf /path/to/malformed/file.ogg
Testcase: https://github.com/RustAudio/lewton/files/2897332/issue_35_hang_new.ogg.gz
Found using AFL.rs, which categorized this issue as a hang.
This issue is distinct from #34 which is about allocating terabytes of virtual memory that is not actually filled.
The text was updated successfully, but these errors were encountered: