Unlike fuzz-dwfl-core, the new fuzz targets actually use zlib so
instead of just linking against zlib to make them compile they
should use the library instrumented with MSan. Without it OSS-Fuzz
reports bogus issues like https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=45630https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=45631 and
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=45633.
To hopefully make it easier to figure out how to add new fuzz targets
going forward I also added the following comment to the build script
```
When new fuzz targets are added it usually makes sense to notify the maintainers of
the elfutils project using the mailing list: elfutils-devel@sourceware.org. There
fuzz targets can be reviewed properly (to make sure they don't fail to compile with -Werror
for example), their names can be chosen accordingly (so as not to spam the mailing
list with bogus bug reports that are opened and closed once they are renamed) and so
on. Also since a lot of bug reports coming out of the blue aren't exactly helpful
fuzz targets should probably be added one at a time to make it easier to keep track
of them.
```
It's a follow-up to https://github.com/google/oss-fuzz/pull/7395
and https://github.com/google/oss-fuzz/pull/7393.
* [elfutils] turn on the alignment check
Unaligned access can crash code on some architectures
like SPARC for example. The latest example (unrelated to elfutils)
would be https://github.com/systemd/systemd/issues/21935 (which UBSan
could have easily prevented and which led to rolling out the check
in the systemd project among other things).
It should probably be merged once https://sourceware.org/bugzilla/show_bug.cgi?id=28720
is closed.
* [elfutils] drop line-tables-only
to make it easier to run the fuzzer with gdb locally.
to make it easier to figure out why configure fails with something like
```
Step #3 - "compile-afl-address-x86_64": configure: error: in `/src/elfutils':
Step #3 - "compile-afl-address-x86_64": configure: error: C compiler cannot create executables
Step #3 - "compile-afl-address-x86_64": See `config.log' for more details
```
The elfutils project was integrated into OSS-Fuzz in
https://github.com/google/oss-fuzz/pull/6670 where
Dockerfile pointed to a fork of the official repository
with a series of patches that were supposed to make it compile
on OSS-Fuzz. Apart from that there was a fuzz target that
effectively wrapped the readelf utility by applying a patch
to its source code. On the whole it worked at the time
but I think there are a few issues:
1. It's hard to point OSS-Fuzz to the official repository
(because most of the patches touch the build system and
they can't always be applied cleanly);
2. It's almost impossible to add new fuzz targets covering
other use cases;
3. It's not possible to build fuzz targets without Docker
4. Since the fuzz target mostly wraps the readelf utility
it looks more like a CLI tool than a fuzz target. It calls
exit when it should just return 0 to let it keep going
and so on.
This PR should addresses all those issues apart from 4. The fuzz
target was just removed and another one was added instead. (It can
be added later though but since it isn't exactly maintainable with
the build script pointing at the official repository it should
probably be rewritten:
https://sourceware.org/pipermail/elfutils-devel/2021q4/004295.html)
The new fuzz target covers the code that `systemd` uses to parse
untrusted data. Currently it can be used to trigger various issues
like heap-buffer-overflows and inifinite loops that in theory can bring down
coredump processing on machines where systemd-coredump is used by
default. Even though those issues were discovered by one of `systemd`
fuzz targets I think elfutils bugs should be caught and reported
by elfutils fuzz targets.
Evgeny Vereshchagin