Need to investigate OSSFuzz failures

[anforowicz]

At the current ToT / origin/master (7dae687) as well as a bit earlier (e.g. at 1ed48eb) fuzzing finds a behavior difference when decoding byte-by-byte:

$ RUST_BACKTRACE=1 cargo fuzz run buf_independent fuzz/artifacts/buf_independent/crash-ab273b8545d715d6608a2c5cb7b73ed6dc853d71
...
INFO: Seed: 3786100926
INFO: Loaded 1 modules   (34736 inline 8-bit counters): 34736 [0x564eaa967630, 0x564eaa96fde0),
INFO: Loaded 1 PC tables (34736 PCs): 34736 [0x564eaa96fde0,0x564eaa9f78e0),
fuzz/target/x86_64-unknown-linux-gnu/release/buf_independent: Running 1 inputs 1 time(s) each.
Running: fuzz/artifacts/buf_independent/crash-ab273b8545d715d6608a2c5cb7b73ed6dc853d71
thread '<unnamed>' panicked at fuzz_targets/buf_independent.rs:77:34:
Small buffer failed Format(FormatError { inner: CorruptFlateStream { err: InvalidDistanceCode } })
stack backtrace:
   0: rust_begin_unwind
             at /rustc/bd53aa3bf7a24a70d763182303bd75e5fc51a9af/library/std/src/panicking.rs:665:5
   1: core::panicking::panic_fmt
             at /rustc/bd53aa3bf7a24a70d763182303bd75e5fc51a9af/library/core/src/panicking.rs:74:14
   2: buf_independent::png_compare
             at ./fuzz/fuzz_targets/buf_independent.rs:77:34
   3: rust_fuzzer_test_input
             at ./fuzz/fuzz_targets/buf_independent.rs:47:13
 ...

Line 77 corresponds to

image-png/fuzz/fuzz_targets/buf_independent.rs

Line 77 in 7dae687

(Ok(_), Err(err)) => panic!("Small buffer failed {:?}", err),

:

    loop {
        let rref = reference.next_frame(&mut ref_data);
        let rsmal = smal.next_frame(&mut smal_data);
        match (rref, rsmal) {
...
            (Ok(_), Err(err)) => panic!("Small buffer failed {:?}", err),  // <== THIS IS LINE 77
            (Err(err), Ok(_)) => panic!("Unexpected success: {:?}", err),
        }
    }

[anforowicz]

I'll try to investigate what causes the difference.

But there is also a question of why this issue (found by running fuzzing on my machine for less than a day) wasn't found and reported earlier by OSSFuzz. I see that image-png has some metadata at https://github.com/google/oss-fuzz/tree/master/projects/image-png, but maybe this is not enough?

[anforowicz]

/cc @jonathanmetzman and @vitorguidi from OSS Fuzz - thanks for looking into this!

An example crash for which I would expect to see a bug can be seen here: https://oss-fuzz.com/testcase-detail/6246780197470208.

I would expect the crash above to result in an automatically opened bug somewhere - ideally underneath https://github.com/image-rs/image-png/issues, since AFAIU this is how the image-png project is configured at https://github.com/google/oss-fuzz/blob/a16a296786de47e27c16c92f9e4f25a036de288b/projects/image-png/project.yaml#L12C1-L12C24

But I'll be happy with a bug anywhere (e.g. in Buganizer, rather than in GitHub).

[fintelia]

I disabled it. See this thread for context.

[anforowicz]

Based on #497 (comment), let me change the focus on this bug from tracking a specific fuzzing issue, to tracking fixing all known fuzzing issues. Until this happens, we may want to disable fuzzing in CI and in OSSFuzz.

I have investigated one of the failing fuzzing inputs. It seems that it may point out a correctness issue in the fdeflate crate - different outcomes (Err vs Ok) may happen depending on how the input is "chunked" when feeding it into fdeflate::Decompressor. A somewhat minimized test case can be found in image-rs/fdeflate#24

[anforowicz]

I looked at the crashes reported at https://oss-fuzz.com/crash-stats?project=image-png:

• buf_independent fuzzer:
  • https://oss-fuzz.com/testcase-detail/6246780197470208: No longer repros with a locally-patched fdeflate (after Prevent spurious InvalidDistanceCode errors fdeflate#26 and Report an error if a block doesn't define any EOF symbol fdeflate#27) and should go away after a new version of fdeflate is released
  • https://oss-fuzz.com/testcase-detail/6611224761008128: Should be fixed by Fix resuming next_frame after UnexpectedEof (APNG trouble). #498
  • https://oss-fuzz.com/testcase-detail/5790077345660928: Should be fixed by Avoid infinite loops in buf_independent fuzzer after real EOF. #499
• roundtrip fuzzer:
  • https://oss-fuzz.com/testcase-detail/5146320858316800: I didn't look at this yet...

[anforowicz]

I've looked at https://oss-fuzz.com/crash-stats?project=image-png and:

• All buf_independent failures seem to be now gone (at least there was no repro since September 29th)
• The page still reports a roundtrip failure at , but I can't repro it locally...

So on one hand, there is still one failure left. OTOH, this may not be actionable unless somebody can repro...