Some fuzzer workarounds

[Evgeny Vereshchagin]

Hi Mark,

>> So I took the fuzz-libelf.c and fuzz-libdwfl.c files from the oss-fuzz
>> repo, tweaked them so they have a normal main that takes one file
>> argument to try to replicate the reports. That found some "real"
>> issues I submitted patches for. Then I ran afl-fuzz on them locally
>> during the weekend and found another issue for which I also submitted
>> a patch.
> 
> FWIW to test the "fuzz" branch I integrated the new fuzz targets into the elfutils build system
> by analogy with https://sourceware.org/pipermail/elfutils-devel/2021q4/004615.html and
> there they are linked with the main function automatically and it's also possible to pass --enable-afl
> to ./configure to automatically run it with AFL.

I sent it to the mailing list: https://sourceware.org/pipermail/elfutils-devel/2022q1/004767.html

> 
>> There are several duplicates though and all the MSAN reported
>> issues seem bogus.
> 
> 
> I'm not sure all of them are bogus but I would ignore them for now. Once the new fuzz targets
> are linked with zlib built with MSan bogus reports will be closed and I'll take a look at what's left
> there.


I can also prevent OSS-Fuzz from reporting new bugs found by MSan
by setting the experimental flag

From https://google.github.io/oss-fuzz/getting-started/new-project-guide/#sanitizers
> If you want to test a particular sanitizer to see what crashes it generates
> without filing them in the issue tracker, you can set an experimental flag

It should help to figure out whether it makes sense to keep it without spamming the mailing list
in the process. What do you think?

Thanks,
Evgeny Vereshchagin