Several issues/questions about atheris HOT 3 CLOSED

Hi David,

Sorry it took me so long to get back to you; I've been working on solving #1. Basically, the problem is this: when ASan or UBSan are preloaded, they define certain coverage symbols, and those take precedence over the symbols defined in libFuzzer (which is loaded later). When statically linked, this is solved by ASan/UBSan having weak versions of those symbols, meaning the libFuzzer symbols take precedence. But when they're preloaded, that doesn't work, and libFuzzer doesn't get coverage info. This actually affects native code too, not just Python code.

I've got a solution, but it's horrid. It involves generating patched versions of ASan/UBSan that don't export the weak symbols that should belong to libFuzzer. However, the patch is really fragile. Better solutions would be to either (1) modify LLVM to generate these modified ASan and UBSan shared objects itself, or (2) statically link ASan/UBSan and libFuzzer into the python runtime, and don't link libFuzzer into the Atheris extension.

For question #2, everything should work just like libFuzzer.

For question #3, I think g++ would work too, as long as the pieces were compiled with clang++, but I'm not sure about that.

from atheris.

Hi David,

I've updated Atheris with a solution to #1. It doesn't work (yet) with OSS-Fuzz, but seems to solve all the problems. It's much less horrid than my other solution, thankfully!

from atheris.

Thanks a lot for your explanation as well as the update. Looking forward to following this project.

from atheris.