libafl pointers getting corrupted when a harness function overflows (mac m4)

[Xplo8E]

IMPORTANT

1. You have verified that the issue to be present in the current main branch

Thank you for making LibAFL better!

Describe the bug

I have used Libafl at main branch with commit a2eb6ecf822e2a30839f1b698ae3640556f9507d

cargo 1.91.1 (ea2d97820 2025-10-10)
rustup 1.28.2 (e4f3ad6f8 2025-04-28)

The target function processVulnerableImageFromFile: has a stack buffer overflow. When it overflows, it writes past its stack frame and corrupts memory that belongs to:

  ┌─────────────────────────────┐  High addresses
  │  LibAFL's executor state    │  ← gets corrupted
  │  (fuzzer, state, mgr ptrs)  │
  ├─────────────────────────────┤
  │  Frida helper data          │  ← gets corrupted
  ├─────────────────────────────┤
  │  harness function      │
  ├─────────────────────────────┤
  │  processVulnerableImageFromFile  │
  │  [BUFFER OVERFLOW HAPPENS]  │  ← overflow writes upward
  │  local buffer               │
  └─────────────────────────────┘  Low addresses

attaching debugger revealed this:

(lldb) process attach --pid 24973
Process 24973 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x1111111111111111)
    frame #0: 0x0000000100a93d40 libafl_fuzzer`libafl::executors::hooks::unix::unix_signal_handler::inproc_crash_handler::hcff683bd75bb190a + 3952
libafl_fuzzer`libafl::executors::hooks::unix::unix_signal_handler::inproc_crash_handler::hcff683bd75bb190a:
->  0x100a93d40 <+3952>: ldp    q0, q1, [x23]
    0x100a93d44 <+3956>: ldp    q2, q3, [x23, #0x20]
    0x100a93d48 <+3960>: stp    q2, q3, [x0, #0x20]
    0x100a93d4c <+3964>: stp    q0, q1, [x0]
Target 0: (libafl_fuzzer) stopped.
Executable binary set to "/Users/vinay/research_libafl_mac_patch/libafl_fuzzer/target/release/libafl_fuzzer".
Architecture set to: arm64-apple-macosx-.
(lldb) bt
warning: could not execute support code to read Objective-C class data in the process. This may reduce the quality of type information available.

* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x1111111111111111)
  * frame #0: 0x0000000100a93d40 libafl_fuzzer`libafl::executors::hooks::unix::unix_signal_handler::inproc_crash_handler::hcff683bd75bb190a + 3952
    frame #1: 0x0000000100c003f4 libafl_fuzzer`libafl::executors::hooks::unix::unix_signal_handler::_$LT$impl$u20$exceptional..unix_signals..SignalHandler$u20$for$u20$libafl..executors..hooks..inprocess..InProcessExecutorHandlerData$GT$::handle::hfe2882b0a0512d66 + 100
    frame #2: 0x0000000100b05b98 libafl_fuzzer`exceptional::unix_signals::handle_signal::h7138974ceaf314e5 + 132
    frame #3: 0x0000000100da0150 libafl_fuzzer`gum_exceptor_backend_on_signal + 448
    frame #4: 0x000000019456d6a4 libsystem_platform.dylib`_sigtramp + 56
    frame #5: 0x000000019443ca94 libsystem_c.dylib`__abort + 164
    frame #6: 0x000000019442d818 libsystem_c.dylib`__stack_chk_fail + 96
    frame #7: 0x0000000102b1f65c libImageLab-ObjC.dylib`-[ImageProcessor processVulnerableImageFromFile:](self=0x0000000324a04080, _cmd="processVulnerableImageFromFile:", filePath=0x0000000000000000) at ImageProcessor.m:662:1

To Reproduce

This is my fuzzer code: https://gist.github.com/Xplo8E/cabb92c9a0b128d38856e61d2d9accbe

Expected behavior

The fuzzer executions increased and same after sometime, at this phase attach debugger to check the issue

[Testcase    #1]  (GLOBAL) run time: 0s, clients: 1, corpus: 35, objectives: 0, executions: 10249, exec/sec: 0.000, edges: 0.305%
       (CLIENT) corpus: 35, objectives: 0, executions: 10249, exec/sec: 0.000, edges: 200/65536 (0%)
[UserStats   #1]  (GLOBAL) run time: 1s, clients: 1, corpus: 35, objectives: 0, executions: 19838, exec/sec: 18.52k, edges: 0.325%
      (CLIENT) corpus: 35, objectives: 0, executions: 19838, exec/sec: 18.52k, edges: 213/65536 (0%)
[Testcase    #1]  (GLOBAL) run time: 1s, clients: 1, corpus: 36, objectives: 0, executions: 19838, exec/sec: 18.43k, edges: 0.325%
       (CLIENT) corpus: 36, objectives: 0, executions: 19838, exec/sec: 18.43k, edges: 213/65536 (0%)
[Broker Heartbeat #0]  (GLOBAL) run time: 31s, clients: 1, corpus: 36, objectives: 0, executions: 19838, exec/sec: 638.3, edges: 0.325%
    (CLIENT) corpus: 0, objectives: 0, executions: 0, exec/sec: 0.000
[Broker Heartbeat #0]  (GLOBAL) run time: 1m-1s, clients: 2, corpus: 36, objectives: 0, executions: 19838, exec/sec: 324.8, edges: 0.325%
    (CLIENT) corpus: 0, objectives: 0, executions: 0, exec/sec: 0.000
[Broker Heartbeat #0]  (GLOBAL) run time: 1m-31s, clients: 2, corpus: 36, objectives: 0, executions: 19838, exec/sec: 217.8, edges: 0.325%
    (CLIENT) corpus: 0, objectives: 0, executions: 0, exec/sec: 0.000
[Broker Heartbeat #0]  (GLOBAL) run time: 2m-1s, clients: 2, corpus: 36, objectives: 0, executions: 19838, exec/sec: 163.8, edges: 0.325%
    (CLIENT) corpus: 0, objectives: 0, executions: 0, exec/sec: 0.000
[Broker Heartbeat #0]  (GLOBAL) run time: 2m-31s, clients: 2, corpus: 36, objectives: 0, executions: 19838, exec/sec: 131.3, edges: 0.325%
    (CLIENT) corpus: 0, objectives: 0, executions: 0, exec/sec: 0.000
[Broker Heartbeat #0]  (GLOBAL) run time: 3m-1s, clients: 2, corpus: 36, objectives: 0, executions: 19838, exec/sec: 109.5, edges: 0.325%
    (CLIENT) corpus: 0, objectives: 0, executions: 0, exec/sec: 0.000
[Broker Heartbeat #0]  (GLOBAL) run time: 3m-31s, clients: 2, corpus: 36, objectives: 0, executions: 19838, exec/sec: 93.98, edges: 0.325%

[s1341]

What would you expect to happen in this case? Are you using Frida-ASAN?

[Xplo8E]

The fuzzer executions increased and same after sometime, at this phase attach debugger to check the issue

Small mistake here, the fuzzer executions count stuck after sometime, and when i checked with debugger i found the pointers got corrputed. And I'm not using any frida-asan