Qemu launcher bugfix #2858
Qemu launcher bugfix #2858
Conversation
| @@ -241,9 +241,9 @@ impl<M: Monitor> Instance<'_, M> { | |||
|
|
|||
| executor | |||
| .run_target( | |||
| &mut NopFuzzer::new(), | |||
| &mut fuzzer, | |||
There was a problem hiding this comment.
this is the problem of the bug.
remember the function enter_target. where you write the pointer to the executor, state, eventmgr, fuzzer, and input to the global.
The types of those are the ones passed into the argument here. so nopfuzzer and nopeventmanager
There was a problem hiding this comment.
however when you recover from the signal. you call inproc crash handler and run_observers_and_save_state
but the types used in that function is the one used when you define them. thus stdfuzzzer and the normal event manager
so this is a type confusion
There was a problem hiding this comment.
IMO the solution is to forcing every inprocess executor to hold the type S and Z (by adding them to phantom data)
There was a problem hiding this comment.
actually i think this is the first time i saw that our unsafe things in inprocess executor is causing a problem...
There was a problem hiding this comment.
Can it be related to the type refactoring or something? Or recent changes otherwise?
There was a problem hiding this comment.
no no ... this happened before he merged those changes i think...
and i just explained above how it happened.
1 .
when you recover from the signal. you call inproc crash handler and run_observers_and_save_state
but the types used in that function is the one used when you define them.
remember the function enter_target. where you write the pointer to the executor, state, eventmgr, fuzzer, and input to the global.
The types of those are the ones passed into the argument here. so nopfuzzer and nopeventmanager
You write the pointer of an object in 1. thinking this is the type Z. but when you recover the pointer in 2., the rust code thinks it is the type of Z'
| .map(|h| h.tokens.clone()) | ||
| .unwrap_or_default() | ||
| } else { | ||
| Vec::new() |
There was a problem hiding this comment.
@rmalmain is there a better option for this? .maybe_extra_token that takes a Some or so?
Also, we should find a way to add CI for this
simplemgrfeatures inCargo.toml(P.S. Currently, another issue potentially related to the
AsanModulehas been observed and may be further discussed in Strange behavior with the AsanModule in LibAFL_qemu #2837.)