Integer divide-by-zero in afl-fuzz.exe

[ghost]

Hi, I've built WinAFL from master branch (last commit b291220), using Visual Studio 2019 (also tried with 2022) Using latest DynamoRIO (last commit 0c479bf)

I'm trying to run the afl-fuzz with test.exe, feeding with corpus "test" This is my command line: afl-fuzz.exe -i in -o out -t 2000 -D "C:\Users\dev\Desktop\dynamorio-master\build\bin32" -- -- test.exe @@

The fuzzer is firing up:

WinAFL 1.16b by <ifratric@google.com>
Based on AFL 2.43b by <lcamtuf@google.com>
[+] You have 4 CPU cores with average utilization of 0%.
[+] Try parallel jobs - see afl_docs\parallel_fuzzing.txt.
[*] Checking CPU core loadout...
[+] Found a free CPU core, binding to #0.
[+] Process affinity is set to 1.
[*] Setting up output directories...
[+] Output directory exists but deemed OK to reuse.
[*] Deleting old session data...
[+] Output dir cleanup successful.
[*] Scanning 'in'...
[+] No auto-generated dictionary tokens to reuse.
[*] Creating hard links for all input files...

[+] Here are some useful stats:

    Test case count : 0 favored, 0 variable, 1 total
       Bitmap range : 0 to 0 bits (average: 0.00 bits)
        Exec timing : 0 to 0 us (average: 0 us)

[+] All set and ready to roll!

                   WinAFL 1.16b based on AFL 2.43b (test.exe)

+- process timing -------------------------------------+- overall results ----+
|        run time : 0 days, 0 hrs, 0 min, 0 sec        |  cycles done : 0     |
|   last new path : none seen yet                      |  total paths : 1     |
| last uniq crash : none seen yet                      | uniq crashes : 0     |
|  last uniq hang : none seen yet                      |   uniq hangs : 0     |
+- cycle progress --------------------+- map coverage -+----------------------+
|  now processing : 0* (0.00%)        |    map density : 0.00% / 0.00%        |
| paths timed out : 0 (0.00%)         | count coverage : 0.00 bits/tuple      |
+- stage progress --------------------+ findings in depth --------------------+
|  now trying : init                  | favored paths : 0 (0.00%)             |
| stage execs : 0/-                   |  new edges on : 0 (0.00%)             |
| total execs : 0                     | total crashes : 0 (0 unique)          |
|  exec speed : infty/sec             |  total tmouts : 0 (0 unique)          |
+- fuzzing strategy yields -----------+---------------+- path geometry -------+
|   bit flips : 0/0, 0/0, 0/0                         |    levels : 1         |
|  byte flips : 0/0, 0/0, 0/0                         |   pending : 1         |
| arithmetics : 0/0, 0/0, 0/0                         |  pend fav : 0         |
|  known ints : 0/0, 0/0, 0/0                         | own finds : 0         |
|  dictionary : 0/0, 0/0, 0/0                         |  imported : n/a       |
|       havoc : 0/0, 0/0                              | stability : n/a       |
|        trim : n/a, n/a                              +-----------------------+
[*] Entering queue cycle 1.---------------------------+   [cpu000001:   2%]
[*] Fuzzing test case #0 (1 total)...
0 processes nudged
nudge operation failed, verify permissions and parameters.

And after couple of seconds, the fuzzer crashes. And I get this crash everytime, with different parameters (tried without instrumentation, different targets, different build versions, architecture).

This is the crash along with the call stack:

First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
*** WARNING: Unable to verify checksum for afl-fuzz.exe
eax=00000000 ebx=00b37928 ecx=00000000 edx=00000000 esi=00000007 edi=00000000
eip=008e8b64 esp=00aef960 ebp=00aef990 iopl=0         nv up ei pl zr na pe nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00010246
afl_fuzz!_aulldiv+0x14:
008e8b64 f7f1            div     eax,ecx

0:000> k 6
 # ChildEBP RetAddr      
00 00aef964 008d3256     afl_fuzz!_aulldiv+0x14 [d:\a01\_work\11\s\src\vctools\crt\vcstartup\src\helper\i386\ulldiv.asm @ 88] 
01 00aef990 008d66a7     afl_fuzz!argv_to_cmd+0x7f6
02 00aefc88 008e0317     afl_fuzz!fscanf+0x307
03 00aefcb4 008e936c     afl_fuzz!main+0x16c7
04 (Inline) --------     afl_fuzz!invoke_main+0x1c [d:\a01\_work\11\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl @ 78] 
05 00aefcfc 76a2fa29     afl_fuzz!__scrt_common_main_seh+0xfa [d:\a01\_work\11\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl @ 288] 

Am I doing something wrong?

This is my build toolset: Windows 10.0.19044 Windows SDK version 10.0.19041.0 MSVC 19.29.30143.0

[ifratric]

I don't see where the integer division occurs (the call stack appears incorrect, building with debug info might resolve that). However, your command line is missing instrumentation option (between first and second --) and I suspect that's causing the issue. See https://github.com/googleprojectzero/winafl/blob/master/readme_dr.md for some usage examples.

[ghost]

I'm not sure if it's related to the instrumentation options, because I've seen this example in the readme_dr: afl-fuzz.exe -e -i in -o out -D <dynamorio bin path> -t 100+ -- -- test_gdiplus.exe @@ which doesn't use any instrumentation options. I tried to follow the same thing with test_gdiplus, and I still get div by zero. I've also executed the instrumentation with drrun.exe, as its usage described in the readme_dr aswell, and it worked properly. The output of WinDBG in the first issue description is of afl-fuzz, compiled with Debug config, so please let me know what else I can do to bring more info.

[sgabe]

Note that the -e switch requires a proper configuration file in the tools subdirectory of the root of DynamoRIO called winafl.drrun32 or winafl.drrun64, depending on the target architecture. However, there is no -e switch in your opening post, hence the instrumentation options should be specified in the command line.