"linked panic runtime not compiled with ..." error #120
Comments
|
a little background here. if a rust program is being fuzzed by afl and the rust program panics (via serde_derive has a a couple initial thoughts:
|
|
I've also hit this issue with a proc-macro crate. Interestingly, I can use cargo-fuzz without problems. Minimal demo project with both afl and cargo-fuzz setup for reproduction: |
|
@birkenfeld @osa1 i opened a new PR that avoids changing the panic strategy in an attempt to fix this: #123 if either of y'all have some time, would be curious to hear if this fixes your issues: |
|
That worked. Thanks @frewsxcv . |
|
Works for me too! |
|
Although, I still wonder why |
|
fyi, i just published afl 0.3.0 which has the fix in #123 |
**Context:** For the fuzzer to be able to "understand" that something went wrong, like a panic, the process must terminate in an abnormal fashion. The default panic hook will unwind the stack, run destructors, optionally print a backtrace and exit with code 101. The fuzzer will not be able to "understand" that something wwnt particuliarly wrong. One way to stop a process in a way that the fuzzer understands as abnormal is to call `std::process::abort()`. **Possible solutions:** - build with "-C panic=abort": incompatible with compiler plugins rust-lang/cargo#2738 (comment) rust-fuzz/afl.rs#120 - use `panic::catch_unwind()` to catch unwinding stacks and call `std::process::abort()`: all kind of bugs will then unwind their stack up to the code calling this function and therefore render different bugs indistinguishable from the fuzzer point of view. - use a custom panic hook and call `std::process::abort()` here. **Implemented solution** We implemented both solution 2 and 3. Solution 3 has no drawbacks that I know of, but could potentially be missed if the fuzzed code modifies the panic hook. In this case, we fall back to solution 2 as a last resort.
**Context:** For the fuzzer to be able to "understand" that something went wrong, like a panic, the process must terminate in an abnormal fashion. The default panic hook will unwind the stack, run destructors, optionally print a backtrace and exit with code 101. The fuzzer will not be able to "understand" that something went particuliarly wrong. One way to stop a process in a way that the fuzzer understands as abnormal is to call `std::process::abort()`. **Possible solutions:** - build with "-C panic=abort": incompatible with compiler plugins rust-lang/cargo#2738 (comment) rust-fuzz/afl.rs#120 - use `panic::catch_unwind()` to catch unwinding stacks and call `std::process::abort()`: all kind of bugs will then unwind their stack up to the code calling this function and therefore render different bugs indistinguishable from the fuzzer's point of view. - use a custom panic hook and call `std::process::abort()` here. **Implemented solution** We implemented both solution 2 and 3. Solution 3 has no drawbacks that I know of, but could potentially be missed if the fuzzed code modifies the panic hook. In this case, we fall back to solution 2 as a last resort.
I get this error when I try running an example in my repo with afl.rs.
The text was updated successfully, but these errors were encountered: