oss-fuzz
oss-fuzz copied to clipboard
Reproducer format change?
I am manually parsing testcases to inject them into Go Fuzz tests.
So far I have been able to use binary.BigEndian.Uint32(b)
to retrieve an input length and pass that number of bytes after the size, if it matches.
However the most recent testcase looks like this:
$ hexdump clusterfuzz-testcase-minimized-FuzzFSECompress-5543357962911744
0000000 20ff 1700 0408 0606 0a0a 0301 0a0a 0a0a
0000010 200a
0000012
A length of 0xff200017
doesn't make sense as a size. I was unable to find any information on how to parse the testcases properly. Can someone assist in this?
One easy workaround may be to print the byte array inside the Go fuzz target, after it was parsed into a Go data structure? Then confirm that the printed version from clusterfuzz-testcase-minimized-FuzzFSECompress-5543357962911744
and your manually added testcase is the same?
@maflcko The testcase is from an oss-fuzz report - I do not have a way to extract it, sine it isn't running locally. I need to be able to extract the the raw input into my Go code to run the reproducer.
@klauspost did you ever managed to do this? I'm running into the same issue where I need to turn a testcase into a Go test to try and understand what is happening.
@erikdubbelboer No. I do find it amazing that noone can provide this (seemingly) simple information - or at least where my assumption is wrong.
@AdamKorcz can you assist here?
I wrote a corpus converter a while back which may be outdated now from changes elsewhere in the infrastructure: https://github.com/google/oss-fuzz/blob/master/infra/base-images/base-runner/gocoverage/convertcorpus/main.go. I can definitely go through it and make sure that it works!
It works by taking in an OSS-Fuzz testcase and outputting the Golang seed.
I will go through it and keep you updated!
So following dependencies I get to this seems to be something like a "decoder" for it. Seems a lot of the weirdness was introduced in https://github.com/AdaLogics/go-fuzz-headers/pull/112
I will not claim it makes much sense. But if it works, at least I'll be able to import the crashes I get.
This seemed to have worked for me. Only it didn't reproduce the out-of-memory condition oss-fuzz encountered, I was already afraid it was because of another reason.
cd ~/src/github.com/google/oss-fuzz/infra/base-images/base-runner/gocoverage/convertcorpus
mkdir rawfuzzers
cp ~/src/github.com/valyala/fasthttp/fuzz_test.go rawfuzzers/FuzzResponseReadLimitBody
go run main.go FuzzResponseReadLimitBody clusterfuzz-testcase-minimized-fuzzResponseReadLimitBody-4525100191776768
This replaces clusterfuzz-testcase-minimized-fuzzResponseReadLimitBody-4525100191776768
with a Go compatible corpus file.