Here's a case that I believe is different from #133: Running this 504 byte input file through the decode function takes ~30 seconds in release mode (at about 170% CPU load according to htop) until it fails with Io(Custom { kind: UnexpectedEof, error: "failed to fill whole buffer" }).
id:000010,sig:06,src:000016,op:flip32,pos:163.tar.gz
To reproduce, in the afl branch (#131), run:
$ time cargo run --release --bin reproduce_decode out/crashes/id:000010,sig:06,src:000016,op:flip32,pos:163
Finished release [optimized] target(s) in 0.01s
Running `target/release/reproduce_decode 'out/crashes/id:000010,sig:06,src:000016,op:flip32,pos:163'`
Decoder returned an error: Io(Custom { kind: UnexpectedEof, error: "failed to fill whole buffer" })
Note: Not a panic, this is fine.
real 0m29.794s
user 0m50.215s
sys 0m2.310s
While running, according to htop, the process does not fill my system memory, that's why I think it's not limited to the "unchecked pre-allocation" issue.
(I hope I don't annoy you with all those issues. Without knowledge of the internals it's hard to judge which cases are duplicates and which cases aren't 🙂 Thanks for developing and maintaining jpeg-decoder!)
Here's a case that I believe is different from #133: Running this 504 byte input file through the decode function takes ~30 seconds in release mode (at about 170% CPU load according to htop) until it fails with
Io(Custom { kind: UnexpectedEof, error: "failed to fill whole buffer" }).id:000010,sig:06,src:000016,op:flip32,pos:163.tar.gz
To reproduce, in the
aflbranch (#131), run:While running, according to htop, the process does not fill my system memory, that's why I think it's not limited to the "unchecked pre-allocation" issue.
(I hope I don't annoy you with all those issues. Without knowledge of the internals it's hard to judge which cases are duplicates and which cases aren't 🙂 Thanks for developing and maintaining
jpeg-decoder!)