Closed Marsman1996 closed 3 years ago
Hi, can you run it under valgrind and report any error? That line of code belongs to qemu, https://github.com/qemu/qemu/blob/master/linux-user/syscall.c#L8488, it is weird that the problem is what you describe.
I run '$ ~/valgrind-3.17.0/bin/bin/valgrind ~/AFLplusplus/qemu_mode/qemuafl/build/qemu-x86_64 ./system' and it reports
==17143== Memcheck, a memory error detector
==17143== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==17143== Using Valgrind-3.17.0 and LibVEX; rerun with -h for copyright info
==17143== Command: /home/ubuntu/AFLplusplus/qemu_mode/qemuafl/build/qemu-x86_64 ./system
==17143==
==17143== Warning: ignored attempt to set SIGKILL handler in sigaction();
==17143== the SIGKILL signal is uncatchable
==17143== Warning: ignored attempt to set SIGRT32 handler in sigaction();
==17143== the SIGRT32 signal is used internally by Valgrind
==17143== Warning: bad signal number 65 in sigaction()
==17143== Warning: bad signal number 65 in sigaction()
==17143== Warning: bad signal number 65 in sigaction()
==17143== Warning: bad signal number 65 in sigaction()
==17157== Invalid read of size 1
==17157== at 0x4C3961C: __strncmp_sse42 (vg_replace_strmem.c:666)
==17157== by 0x23F3BF: do_syscall1 (syscall.c:8511)
==17157== by 0x2499B5: do_syscall (syscall.c:13355)
==17157== by 0x164791: cpu_loop (cpu_loop.c:243)
==17157== by 0x269D9D: main (main.c:878)
==17157== Address 0x0 is not stack'd, malloc'd or (recently) free'd
==17157==
qemu:handle_cpu_signal received signal outside vCPU context @ pc=0x4c3961e
==17157==
==17157== Process terminating with default action of signal 6 (SIGABRT)
==17157== at 0x5D7AFB7: raise (raise.c:51)
==17157== by 0x5D7C9FA: abort (abort.c:100)
==17157== by 0x1CD700: handle_cpu_signal (user-exec.c:133)
==17157== by 0x1CDBF3: cpu_x86_signal_handler (user-exec.c:349)
==17157== by 0x25A010: host_signal_handler (signal.c:718)
==17157== by 0x5B2F97F: ??? (in /lib/x86_64-linux-gnu/libpthread-2.27.so)
==17157== by 0x4C3961B: __strncmp_sse42 (vg_replace_strmem.c:666)
==17157== by 0x23F3BF: do_syscall1 (syscall.c:8511)
==17157== by 0x2499B5: do_syscall (syscall.c:13355)
==17157== by 0x164791: cpu_loop (cpu_loop.c:243)
==17157== by 0x269D9D: main (main.c:878)
==17157==
==17157== HEAP SUMMARY:
==17157== in use at exit: 1,135,028 bytes in 4,196 blocks
==17157== total heap usage: 6,354 allocs, 2,158 frees, 1,413,090 bytes allocated
==17157==
==17157== LEAK SUMMARY:
==17157== definitely lost: 0 bytes in 0 blocks
==17157== indirectly lost: 0 bytes in 0 blocks
==17157== possibly lost: 0 bytes in 0 blocks
==17157== still reachable: 1,135,028 bytes in 4,196 blocks
==17157== suppressed: 0 bytes in 0 blocks
==17157== Rerun with --leak-check=full to see details of leaked memory
==17157==
==17157== For lists of detected and suppressed errors, rerun with: -s
==17157== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
==17143==
==17143== HEAP SUMMARY:
==17143== in use at exit: 1,142,116 bytes in 4,367 blocks
==17143== total heap usage: 6,559 allocs, 2,192 frees, 1,423,666 bytes allocated
==17143==
==17143== LEAK SUMMARY:
==17143== definitely lost: 0 bytes in 0 blocks
==17143== indirectly lost: 0 bytes in 0 blocks
==17143== possibly lost: 288 bytes in 1 blocks
==17143== still reachable: 1,141,828 bytes in 4,366 blocks
==17143== suppressed: 0 bytes in 0 blocks
==17143== Rerun with --leak-check=full to see details of leaked memory
==17143==
==17143== For lists of detected and suppressed errors, rerun with: -s
==17143== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
Glad it's fixed. 😀
When running qemu_mode of AFL++, it didn't execute function 'sysyem()', such as the simple example
When I ran '$ /AFLplusplus/afl-qemu-trace ./system', it returns
I believe it's because of the unproper condition statement in https://github.com/AFLplusplus/qemuafl/blob/0fb212daab492411b3e323bc18a3074c1aecfd37/linux-user/syscall.c#L8498 It should be