SIGILL while compiling a project with afl.rs

[Geal]

Hi,

I do not know if this bug comes from my setup or from afl.rs, so I'll post it here. I am trying to setup fuzzing for a tar parser built with nom, but I get a SIGILL while building the project. Here is the GDB output for the incriminated rustc call:

(gdb) r src/main.rs --crate-name tar_example --crate-type bin -g --out-dir /home/geal/fuzzing/tar-parser.rs/fuzzed/target/debug --emit=dep-info,link -L dependency=/home/geal/fuzzing/tar-parser.rs/fuzzed/target/debug -L dependency=/home/geal/fuzzing/tar-parser.rs/fuzzed/target/debug/deps --extern afl_coverage=/home/geal/fuzzing/tar-parser.rs/fuzzed/target/debug/deps/libafl_coverage-b12fdfb78ced2df1.rlib --extern tar=/home/geal/fuzzing/tar-parser.rs/fuzzed/target/debug/deps/libtar-8c75079877dd814c.rlib --extern afl_coverage_plugin=/home/geal/fuzzing/tar-parser.rs/fuzzed/target/debug/deps/libafl_coverage_plugin-38726c8cba86ad1b.so --extern nom=/home/geal/fuzzing/tar-parser.rs/fuzzed/target/debug/deps/libnom-8d822f881e715e50.rlib -L native=/home/geal/fuzzing/tar-parser.rs/fuzzed/target/debug/build/afl-coverage-b12fdfb78ced2df1/out -L native=/home/geal/fuzzing/tar-parser.rs/fuzzed/target/debug/build/afl-coverage-b12fdfb78ced2df1/out
Starting program: /usr/local/bin/rustc src/main.rs --crate-name tar_example --crate-type bin -g --out-dir /home/geal/fuzzing/tar-parser.rs/fuzzed/target/debug --emit=dep-info,link -L dependency=/home/geal/fuzzing/tar-parser.rs/fuzzed/target/debug -L dependency=/home/geal/fuzzing/tar-parser.rs/fuzzed/target/debug/deps --extern afl_coverage=/home/geal/fuzzing/tar-parser.rs/fuzzed/target/debug/deps/libafl_coverage-b12fdfb78ced2df1.rlib --extern tar=/home/geal/fuzzing/tar-parser.rs/fuzzed/target/debug/deps/libtar-8c75079877dd814c.rlib --extern afl_coverage_plugin=/home/geal/fuzzing/tar-parser.rs/fuzzed/target/debug/deps/libafl_coverage_plugin-38726c8cba86ad1b.so --extern nom=/home/geal/fuzzing/tar-parser.rs/fuzzed/target/debug/deps/libnom-8d822f881e715e50.rlib -L native=/home/geal/fuzzing/tar-parser.rs/fuzzed/target/debug/build/afl-coverage-b12fdfb78ced2df1/out -L native=/home/geal/fuzzing/tar-parser.rs/fuzzed/target/debug/build/afl-coverage-b12fdfb78ced2df1/out
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Traceback (most recent call last):
  File "/usr/share/gdb/auto-load/usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.19-gdb.py", line 63, in <module>
    from libstdcxx.v6.printers import register_libstdcxx_printers
ImportError: No module named 'libstdcxx'
[New Thread 0x7fffefbff700 (LWP 13085)]
warning: Missing auto-load scripts referenced in section .debug_gdb_scripts
of file /home/geal/fuzzing/tar-parser.rs/fuzzed/target/debug/deps/libafl_coverage_plugin-38726c8cba86ad1b.so
Use `info auto-load python-scripts [REGEXP]' to list them.
afl-llvm-pass 1.77b by <lszekeres@google.com>

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffefbff700 (LWP 13085)]
0x00007ffff3a57388 in llvm::PointerType::get(llvm::Type*, unsigned int) () from /usr/local/lib/librustc_llvm-d8ace771.so
(gdb) bt
#0  0x00007ffff3a57388 in llvm::PointerType::get(llvm::Type*, unsigned int) () from /usr/local/lib/librustc_llvm-d8ace771.so
#1  0x00007ffff04514a6 in (anonymous namespace)::AFLCoverage::runOnModule(llvm::Module&) () from /home/geal/fuzzing/tar-parser.rs/fuzzed/target/debug/deps/libafl_coverage_plugin-38726c8cba86ad1b.so
#2  0x00007ffff3a3e76f in llvm::FPPassManager::runOnFunction(llvm::Function&) () from /usr/local/lib/librustc_llvm-d8ace771.so
#3  0x00007ffff3a3e84e in llvm::legacy::FunctionPassManagerImpl::run(llvm::Function&) () from /usr/local/lib/librustc_llvm-d8ace771.so
#4  0x00007ffff3a3e944 in llvm::legacy::FunctionPassManager::run(llvm::Function&) () from /usr/local/lib/librustc_llvm-d8ace771.so
#5  0x00007ffff2addc40 in LLVMRustRunFunctionPassManager (PM=0x7fffe8116270, M=0x7fffe8004e00) at /home/geal/dev/rust/rust/src/rustllvm/PassWrapper.cpp:205
#6  0x00007ffff62ea584 in back::write::execute_work_item::h57fe4379208c73afFjd () from /usr/local/lib/librustc_trans-d8ace771.so
#7  0x00007ffff62e3417 in back::write::run_passes::h0b7edf1f79d9711erZc () from /usr/local/lib/librustc_trans-d8ace771.so
#8  0x00007ffff7ac74b4 in driver::phase_5_run_llvm_passes::h401bc1bb79e26ccfJPa () from /usr/local/lib/librustc_driver-d8ace771.so
#9  0x00007ffff7a9a018 in driver::compile_input::h5f7ce1a1b74fe3e9Tba () from /usr/local/lib/librustc_driver-d8ace771.so
#10 0x00007ffff7b769f4 in run_compiler::h99fee4b1ff194bd3x7b () from /usr/local/lib/librustc_driver-d8ace771.so
#11 0x00007ffff7b743cf in boxed::F.FnBox$LT$A$GT$::call_box::h15186281694418648608 () from /usr/local/lib/librustc_driver-d8ace771.so
#12 0x00007ffff7b73c1a in rt::unwind::try::try_fn::h4127295356855569320 () from /usr/local/lib/librustc_driver-d8ace771.so
#13 0x00007ffff75db1d9 in rust_try_inner () from /usr/local/lib/libstd-d8ace771.so
#14 0x00007ffff75db1c6 in rust_try () from /usr/local/lib/libstd-d8ace771.so
#15 0x00007ffff754eb68 in rt::unwind::try::inner_try::hc82de977351d5e1crJw () from /usr/local/lib/libstd-d8ace771.so
#16 0x00007ffff7b73e2c in boxed::F.FnBox$LT$A$GT$::call_box::h16559282529075441406 () from /usr/local/lib/librustc_driver-d8ace771.so
#17 0x00007ffff7562412 in sys::thread::Thread::new::thread_start::h63af462716e59b66oTv () from /usr/local/lib/libstd-d8ace771.so
#18 0x00007ffff1e75182 in start_thread (arg=0x7fffefbff700) at pthread_create.c:312
#19 0x00007ffff71ab47d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111
(gdb)

I suspect that my version of rustc may be too new (I built it this morning):

$ rustc -V
rustc 1.2.0-dev (e749f724b 2015-06-23)

This is on a Linux machine, but I made it work previously on a Macbook, although with an older rustc:

$ rustc -V
rustc 1.2.0-dev (717e8831b 2015-06-08)

I have to add that this project is a great help, fuzzing the nom projects is fun :)

[Geal]

I just confirmed that on the Linux machine where I encountered the bug, it works correctly with rustc 1.2.0-dev (717e8831b 2015-06-08). So it is an issue with LLVM in Rust.

[neuschaefer]

Based on the good/bad commits mentioned above, I've tracked this issue down to rust-lang/rust@f9d4149 ("rustc: Update LLVM").

[shahn]

Is this something that can be expected to work in the future because Rust pulls in another llvm snapshot, or are we stuck with older rustc versions?

[frewsxcv]

I can't think of any reason why this couldn't be fixed, so hopefully it will be fixed in the future

[karyon]

fwiw there seems to be an assertion in place for this, see #14.

[frewsxcv]

New LLVM upgrade might be coming soon for Rust: rust-lang/rust#30448

Might want to try looking into this again after that happens

[frewsxcv]

I looked into this very briefly this morning. A null deref seems to happen on this line:

https://github.com/frewsxcv/afl.rs/blob/7373294db7b0c452bc6ee453d4c9fa12e5b64a4c/plugin/src/afl-llvm-pass.so.cc#L91-L93

[frewsxcv]

In particular, this statement: PointerType::get(Int8Ty, 0)

[frewsxcv]

Opened a Rust issue for this: rust-lang/rust#31067

[frewsxcv]

Opened a PR on rust-lang/rust that fixes this: rust-lang/rust#31176

[frewsxcv]

rust-lang/rust#31176 has merged which fixes this issue!