The provided log indicates a crash in the QEMU emulator due to a negative size parameter being passed to `memcpy`, which is detected by AddressSanitizer (ASan). This suggests there's a bug in the code that calls `memcpy` with an invalid size argument. The stack trace shows where this issue occurs, starting from `LLVMFuzzerInitialize` in `videzzo_qemu.c` and propagating through various QEMU initialization functions. ### Key Points: 1. **Crash Cause**: A negative size parameter is passed to `memcpy`, which is invalid and causes the program to abort. 2. **Location**: The issue occurs in `asan_interceptors_memintrinsics.cpp` at line 22, which intercepts memory operations for ASan. 3. **Stack Trace**: - The crash originates from `LLVMFuzzerInitialize`. - It propagates through QEMU's initialization functions (`qemu_init`, `machine_run_board_init`, etc.). - The root cause likely lies in the hardware device initialization (`tosa_init`, `tc6393xb_init`, `nand_init`), where a negative size is being passed to `memcpy`. ### Steps to Investigate: 1. **Review Fuzzer Input**: - Check the input provided to the fuzzer to ensure it's valid and doesn't trigger invalid memory operations. 2. **Inspect QEMU Initialization**: - Look at the functions in `tosa_init`, `tc6393xb_init`, and `nand_init` to identify where an invalid size might be calculated or passed. 3. **Check Memory Operations**: - Ensure all calls to `memcpy` (or similar functions) have valid, non-negative size parameters. 4. **Debug with ASan**: - Use ASan's features to track memory allocations and detect the exact point where the invalid size is used. ### Conclusion: The crash indicates a bug in QEMU's initialization process when using the fuzzer. The negative size parameter passed to `memcpy` suggests an issue in how memory operations are handled during device initialization. Investigating the functions in `tosa_init`, `tc6393xb_init`, and `nand_init` will help identify the root cause of this bug.