elfutils: add and expand library fuzzers #7395
Conversation
|
It would be great if seed corpora of some kind could be added to let for example |
| -I. -I./lib -I./libelf -I./libebl -I./libdw -I./libdwelf -I./libdwfl -I./libasm \ | ||
| -c "$SRC/fuzz-libdwfl.c" -o fuzz-libdwfl.o | ||
| $CXX $CXXFLAGS $LIB_FUZZING_ENGINE fuzz-libdwfl.o \ | ||
| ./libasm/libasm.a ./libebl/libebl.a ./backends/libebl_backends.a ./libcpu/libcpu.a \ |
There was a problem hiding this comment.
I wonder why it's linked against these libraries? I opened #7412 where I dropped them but if it's intentional it would be great if there was a comment or something like that. Thanks!
There was a problem hiding this comment.
The intentions were to expand with further fuzzers shortly so the idea was to include all the relevant elfutils libraries and then shrink the build set up to a loop instead of many individual calls to $CXX -- in this event it would be easier to link in all static libraries so as to add a new fuzzer you simply add the fuzzer name. Similar to what we did for the net-snmp library https://github.com/net-snmp/net-snmp/blob/8e14effb6626bbf5bc344ec17fdf0354b5b9a90d/testing/fuzzing/build-fuzz-tests.sh#L7-L20
There was a problem hiding this comment.
Got it. Thanks! I'll go ahead and close that PR then.
I think as long as issues like #7357 aren't triggered it should be possible to link all the fuzz targets with the common set of the libraries.
There was a problem hiding this comment.
Yep, sounds good and thanks for pointing #7357 out.
It's a follow-up to google/oss-fuzz#7395
It's a follow-up to google/oss-fuzz#7395
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=45630 https://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: [email protected]. 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 google#7395 and google#7393.
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=45630 https://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: [email protected]. 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 #7395 and #7393.
It's a follow-up to google/oss-fuzz#7395
|
Looks like the fuzzers report the same issues with different backtraces like https://sourceware.org/bugzilla/show_bug.cgi?id=29000. I haven't looked at the code yet but it appears |
I'll take a look at this end of next week |
It's a follow-up to google/oss-fuzz#7395
It's a follow-up to google/oss-fuzz#7395
|
I took a look at things @evverx There is some intersection between the two in that What is the specific concern though? is it:
|
It's the OSV database mostly. I'd agree that maintainers shouldn't be concerned about it if https://osv.dev/ mentioned that in its current form it isn't suitable for processing and reporting "vulnerabilities" automatically (partly due to some OSS-Fuzz issues). But as long as it can still be used to waste maintainers' time I'm not sure it can be ignored completely. It's also being discussed in #7479 (comment).
Let's just keep them as is then. It's not uncommon for fuzz targets to fuzz the same code after all. It's just that usually to avoid duplicates like that it makes sense to add fuzz targets one at a time once "shallow" bugs are fixed. |
It's a follow-up to google/oss-fuzz#7395
It's a follow-up to google/oss-fuzz#7395
It's a follow-up to google/oss-fuzz#7395
It's a follow-up to google/oss-fuzz#7395
It's a follow-up to google/oss-fuzz#7395
* elfutils: make name more appropriate * elfutils: update libelf fuzzer * elfutils: add fuzz-libdwfl * elfutils: nits * elfutils: fix build
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=45630 https://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: [email protected]. 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 google#7395 and google#7393.
Now fuzz-libdwfl and fuzz-libelf can be run a few times in a row with files triggering crashes. It's another follow-up to google#7395 and google#7393.
It's a follow-up to google/oss-fuzz#7395
It's a follow-up to google/oss-fuzz#7395
It's a follow-up to google/oss-fuzz#7395
No description provided.