afl-bridge: fix race between main thread and a vCPU thread #102
Conversation
|
Hi, @rmalmain, Could you please take a look? |
reformat code with more typedefs.
|
@rmalmain, @domenukk, @vanhauser-thc , @hexcoder-, @andreafioraldi, @tokatoka, May I ask you to take a look at this PR? We really want to use LibAFL for Xen fuzzing on our CI server, but there is an issue that crashes the whole fuzzer. This PR fixes it. If you need more information, please let me know. |
|
I'll tell romain to check it. |
|
Thanks! I waited almost a month, so I'll wait couple days more :) |
| @@ -273,6 +279,12 @@ static void *rr_cpu_thread_fn(void *arg) | |||
| bql_lock(); | |||
| break; | |||
| } | |||
| //// --- Begin LibAFL code --- | |||
There was a problem hiding this comment.
can you also propagate this change to accel/tcg/tcg-accel-ops-mttcg.c please?
There was a problem hiding this comment.
Sure, will do this today.
|
Thank you, I started to run the tests on the main repo.
…-------- Message d'origine --------
Le 13/03/2025 12:46, Volodymyr Babchuk a écrit :
@lorc commented on this pull request.
---------------------------------------------------------------
In [accel/tcg/tcg-accel-ops-rr.c](#102 (comment)):
> @@ -273,6 +279,12 @@ static void *rr_cpu_thread_fn(void *arg)
bql_lock();
break;
}
+//// --- Begin LibAFL code ---
Sure, will do this today.
—
Reply to this email directly, [view it on GitHub](#102 (comment)), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/AAIHINGI2GSVMC5BNRRIJMT2UFVXZAVCNFSM6AAAAABW34E7ZKVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZDMOBRGU4DANZYHE).
You are receiving this because you were mentioned.Message ID: ***@***.***>
|
In some cases qemu_main_loop() can exit before libafl_sync_exit_cpu() completes. This will case race between Rust code that restarts QEMU and vCPU thread that updates last_exit_reason. What I observed is libafl_exit_signal_vm_start() from a new iteration cleared last_exit_reason.cpu before libafl_sync_exit_cpu() tried to access *last_exit_reason.cpu. This caused NULL pointer dereference. Fix this by not setting cpu->exit in prepare_qemu_exit() and updating it only in rr_cpu_thread_fn() and MTTCG counterpart. This will ensure that qemu_main_loop() waits for vCPU thread to actually stop before returning control to the Rust code. Signed-off-by: Volodymyr Babchuk <volodymyr_babchuk@epam.com>
|
Okay, I've updated the PR by adding the complementary change into MTTR. But I didn't tested MTTR case, though. |
|
it should behave similarly. |
In some cases qemu_main_loop() can exit before libafl_sync_exit_cpu() completes. This will case race between Rust code that restarts QEMU and vCPU thread that updates last_exit_reason. What I observed is
libafl_exit_signal_vm_start() from a new iteration cleared last_exit_reason.cpu before libafl_sync_exit_cpu() tried to access *last_exit_reason.cpu. This caused NULL pointer dereference.
Fix this by not setting cpu->exit in prepare_qemu_exit() and updating it only in rr_cpu_thread_fn(). This will ensure that qemu_main_loop() waits for vCPU thread to actually stop before returning control to Rust code.