Crash exec_result_code can be overwritten by the normal sync page_not_found path before host samling, causing real crashes to be reported as regular

Hi,

I observed a real crash misclassification in `kafl.qemu` that appears to come from the upstream result handoff logic.

This is not only a source-level concern: I instrumented the QEMU/Nyx paths locally and directly observed a real `rc_crash` result being overwritten with `rc_success` before the host fuzzer sampled it.

## Observed behavior

A target reliably triggered a real panic/crash path, but the input was sometimes reported to the fuzzer as `regular` instead of `crash`.

After adding tracing around the aux-buffer result flow, I observed this sequence:

1. panic path entered
2. `exec_result_code` set to `rc_crash`
3. reload completed
4. before the next host-visible sync point, `exec_result_code` was overwritten from `rc_crash` to `rc_success`
5. the Python worker then sampled `success` and classified the input as `regular`

## Directly observed overwrite path

The overwrite I observed was:

- terminal result written in the panic/crash path
- then overwritten in the next normal sync path by `page_not_found` handling

In other words, this was not a hypothetical overwrite candidate.
I directly observed:

- `crash -> success`
- at the `synchronization_lock()/page_not_found` path
- before host sampling

## Why this happens

### 1. Host sampling is delayed

In `kafl.fuzzer`, the host does not continuously observe the aux buffer.
It only reads the result when QEMU reaches the next control-socket sync boundary.

Relevant logic is in:
- `kafl_fuzzer/worker/qemu.py`
- `run_qemu()`
- `send_payload()`

So once a terminal result is written, it must remain stable until the next host-visible sync point.

### 2. Crash path writes the result before host sampling

In upstream `kafl.qemu`:

- `handle_hypercall_kafl_panic()`
- `synchronization_lock_crash_found()`

The panic path writes `rc_crash`, performs reload, and returns.
The host does not sample the aux buffer at that exact point.

### 3. The aux result uses a single mutable `exec_result_code` slot

Multiple paths write directly into the same `exec_result_code` byte, including:

- `set_crash_auxiliary_result_buffer()`
- `set_timeout_auxiliary_result_buffer()`
- `set_asan_auxiliary_result_buffer()`
- `set_success_auxiliary_result_buffer()`

So the crash result is not latched.

### 4. The next normal sync path can overwrite it

In the run I traced, the overwrite happened in:

- `synchronization_lock()`
- specifically the `synchronization_check_page_not_found()` / `page_not_found` handling path

That path wrote `success` before the host sampled the earlier crash result.

## Why I think this is an upstream bug

The implementation relies on the assumption that once a terminal result is written, it will still be present when the host reads it later.

But in the current structure:

- terminal result is written first
- host sampling happens later
- normal sync code can still write into the same result slot

That makes the crash-report handoff non-atomic with respect to host observation.

## Expected behavior

If the current execution has already been classified as `crash`, the host should not later observe that same execution as `regular`.

Once `exec_result_code` becomes terminal for an execution, later non-terminal sync logic should not downgrade it before host sampling.

## Suggested fix direction

A robust fix would be:

1. give terminal results (`crash`, `timeout`, `asan`, etc.) a dedicated handoff path,
2. record `exec_done` / runtime / dirty-page metadata there,
3. perform the host `PING`/wait handshake immediately for that terminal result,
4. only reset the result slot after host ACK,
5. prevent normal sync paths from overwriting an already-terminal `exec_result_code`.

## Practical impact

This can cause real crashes to be misclassified as `regular`, depending on the post-reload sync flow.

If useful, I can also provide a minimal patch that fixes this by preserving terminal results until host handoff and guarding the normal sync overwrite path.

Thank you for reading ! :)