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. It still needs polishing but I wonder if it makes sense to send that to the mailing list? I still think the fuzz targets should be kept and reviewed upstream and that patch would make it possible. It's being tested in https://github.com/evverx/elfutils/pull/72. I'll report back once I figure out why the unit tests are failing on Fedora Rawhide: https://copr-be.cloud.fedoraproject.org/results/packit/evverx-elfutils-72/fedora-rawhide-x86_64/03799633-elfutils/builder-live.log.gz > 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. Thanks, Evgeny Vereshchagin
