Segmentation fault in longjmp while collecting coverage

[blabla-my]

Hello everyone. I am trying to collect coverage of qemu 8.0.0 but failed. Details are listed below:

System info

L0 OS: ubuntu20.04, kernel version 6.0.0,
L1 qemu: 8.0.0
L2 qemu: 8.0.0 with clang coverage

Steps

1. Build L2 qemu 8.0.0 with coverage.
2. create a snapshot of qemu 8.0.0. The tree structure of snapshot directory is:

├── layout
├── lspci
├── mem
├── mem.md5sum
├── mtree
├── regs
├── snap.sqlite
├── symbols
│   ├── kvm-intel.ko
│   ├── kvm.ko
│   ├── libc.so.6
│   ├── libglib-2.0.so.0
│   ├── qemu-system-x86_64
│   └── vmlinux
└── vmcs

3. collect coverage:

export SNAPSHOT_BASE=/home/lmy/HyperPill/snapshot/kvm
export PROJECT_ROOT=/home/lmy/HyperPill
export LINK_OBJ_BASE=0x558a5233c000
KVM=1 CORPUS_DIR=./corpus $PROJECT_ROOT/scripts/run_hyperpill2.sh

Output

...
Loaded MMIO Region: febd9000 +7000
Loaded MMIO Region: febda000 +26000
Loaded MMIO Region: fec01000 +ff000
Loaded MMIO Region: fed00000 +10000
Loaded MMIO Region: fed01000 +ff000
Loaded MMIO Region: fee01000 +11ff000
Loaded MMIO Region: 180000000 +10000000
Dictionary: 1 entries
INFO: Running with entropic power schedule (0xFF, 100).
INFO: Seed: 1484418901
INFO: 32768 Extra Counters
INFO:        0 files found in ./corpus
__start___llvm_prf_data: 0000000001b6c1d8
__stop___llvm_prf_data: 0000000001d71438
__start___llvm_prf_cnts: 00000000019c9790
__stop___llvm_prf_cnts: 0000000001b6c1d8
__start___llvm_prf_names: 0000000000c9ef5d
__stop___llvm_prf_names: 00000000013523c2
/home/lmy/HyperPill/scripts/run_hyperpill2.sh: line 48: 684728 Segmentation fault      (core dumped) ./fuzz $LIBFUZZER_FLAGS

Debug result

I tried to debug using GDB. However, after I reached the segmentation fault, backtrace command could not work correctly. I only know the segmentation fault happened in a longjmp.

gef➤  x/i $rip
=> 0x7ffff7653dbe <__longjmp+142>:      jmp    rdx
gef➤  i r rdx
rdx            0x517b4ba1a508d24e  0x517b4ba1a508d24e
gef➤  bt
#0  __longjmp () at ../sysdeps/x86_64/__longjmp.S:111
#1  0x517b4ba1a508d24e in ?? ()
Backtrace stopped: Cannot access memory at address 0x517b4ba1a508d24e

Additional information

1. Fuzz without coverage worked well

[blabla-my]

After further debugging, I find the backtrace of this problem, while calling translate_linear_long_mode() in init_sourcecov(), an exception happened,

gef➤  bt
#0  BX_CPU_C::exception (vector=0xe, error_code=0x1) at ../../bochs/cpu/exception.cc:1012
#1  0x00000000004e1a11 in BX_CPU_C::page_fault (fault=0x1, laddr=0x558a53d05790, user=0x0, rw=0x0) at ../../bochs/cpu/paging.cc:530
#2  0x00000000004e2051 in BX_CPU_C::translate_linear_long_mode (laddr=0x558a53d05790, lpf_mask=@0x7fffffffd340: 0xfff, pkey=@0x7fffffffd344: 0x0, user=0x0, rw=0x0) at ../../bochs/cpu/paging.cc:845
#3  0x000000000044faee in init_sourcecov (baseaddr=<optimized out>) at sourcecov.cc:260
#4  0x000000000040dbda in LLVMFuzzerTestOneInput (Data=0x2030060 "`\303\001\002", Size=0x0) at main.cc:190

The longjmp is at the end of the BX_CPU_C::exception().

HyperPill/vendor/bochs/cpu/exception.cc

Line 1012 in c06c648

longjmp(BX_CPU_THIS_PTR jmp_buf_env, 1); // go back to main decode loop