-
-
Notifications
You must be signed in to change notification settings - Fork 345
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Crash in libafl_maps_next when iterating over qemu.mapping #3010
Comments
can you run literally anything process is ok. i just want to check if you have vsyscall page |
if vsyscall is not there, then it's a problem. (idk if you omit the end of mappings, but if you didn't then vsyscall is apparently missing) You should compile your kernel again and enable vsyscall (just to make |
yeah rbx is pointing to 0xffffffffff600000. so 100% its vsyscall page missing 😄 |
Thank you for the answer, yes vsyscall is off by default now. So there is no way to use these Libafl-qemu features with a recent OS @tokatoka ? I don't understand why the issue is my kernel and not this code that does not check for null value (or something else). Everything is working well except this |
yes we should fix. @rmalmain |
Describe the bug
My fuzzer crash every time a
for map in qemu.mappings() {
is done (in Snapshot helper, QemuMappingsViewer or when I do it in my code) . Same when I run theqemu_coverage
example on latest LibAFL commit (it doeslet mappings = QemuMappingsViewer::new(&qemu);
).To Reproduce
Steps to reproduce the behavior:
Linux pct 6.1.0-30-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.124-1 (2025-01-12) x86_64 GNU/Linux
just run
on qemu_coverage example:The issue is in libalf-qemu-bridge I think. e is NULL but I don't know if it is due to a bug or just that it should be checked for NULL as the comment says:
The result I get when I do a for loop:
The mapping I get from gdb at crash point is:
The text was updated successfully, but these errors were encountered: