SEGV while running Triforce

[mothran]

Hello, I noticed a null deference while running TriforceAFL for long periods of time.

At qemu_mode/qemu/cpus.c:1072

It appears that the cpu->thread->thread is null, I am not sure if this is a QEMU bug or introduced as part of the modifications to the threading model to support AFL.

GDB output of the issue:

Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x000055721c5f6874 in qemu_cpu_kick_thread (cpu=<optimized out>)
    at /TriforceAFL/qemu_mode/qemu/cpus.c:1072 
    	err = pthread_kill(cpu->thread->thread, SIG_IPI);
   0x000055721c5f6868 <qemu_mutex_lock_iothread+120>:	48 8b 05 71 f8 71 00	mov    rax,QWORD PTR [rip+0x71f871]        # 0x55721cd160e0 <cpus>
   0x000055721c5f686f <qemu_mutex_lock_iothread+127>:	be 0a 00 00 00	mov     esi,0xa
=> 0x000055721c5f6874 <qemu_mutex_lock_iothread+132>:	48 8b 80 88 00 00 00	mov    rax,QWORD PTR [rax+0x88]
   0x000055721c5f687b <qemu_mutex_lock_iothread+139>:	48 8b 38	            mov    rdi,QWORD PTR [rax]
   0x000055721c5f687e <qemu_mutex_lock_iothread+142>:	e8 0d e2 fb ff	        call   0x55721c5b4a90
[Current thread is 1 (Thread 0x7f2a1a64ad80 (LWP 3092))]
(gdb) bt
#0  0x000055721c5f6874 in qemu_cpu_kick_thread (cpu=<optimized out>)
    at /TriforceAFL/qemu_mode/qemu/cpus.c:1072
#1  0x000055721c5f6874 in qemu_mutex_lock_iothread () at /TriforceAFL/qemu_mode/qemu/cpus.c:1147
#2  0x000055721c88045b in os_host_main_loop_wait (timeout=3895265) at main-loop.c:242
#3  0x000055721c88045b in main_loop_wait (nonblocking=<optimized out>) at main-loop.c:494
#4  0x000055721c5b99fd in main_loop () at vl.c:1802
#5  0x000055721c5b99fd in main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at vl.c:4375
(gdb) i r
rax            0x0	0
rbx            0x1	1
rcx            0x7f29ff7a6551	139818356598097
rdx            0x1	1
rsi            0xa	10
rdi            0x55721cdcfc80	93948598877312
rbp            0x7fff3c9e8774	0x7fff3c9e8774
rsp            0x7fff3c9e8760	0x7fff3c9e8760
r8             0x8	8
r9             0x0	0
r10            0x0	0
r11            0x0	0
r12            0x3b6fe1	3895265
r13            0x55721c932e6b	93948594040427
r14            0x55721cdd6b60	93948598905696
r15            0x55721d7dc9e0	93948609415648
rip            0x55721c5f6874	0x55721c5f6874 <qemu_mutex_lock_iothread+132>
eflags         0x10202	[ IF RF ]
cs             0x33	51
ss             0x2b	43
ds             0x0	0
es             0x0	0
fs             0x0	0
gs             0x0	0
(gdb) list
1067	static void qemu_cpu_kick_thread(CPUState *cpu)
1068	{
1069	#ifndef _WIN32
1070	    int err;
1071	
1072	    err = pthread_kill(cpu->thread->thread, SIG_IPI);
1073	    if (err) {
1074	        fprintf(stderr, "qemu:%s: %s", __func__, strerror(err));
1075	        exit(1);
1076	    }

[jhertz]

i am not sure whether this is a bug in the vanilla QEMU_MODE, or in our modifications to it. we ran TriforceAFL for months at a time, so it is strange that we did not see this crash (perhaps you have built it with a different compiler, or in your fuzzing have managed to reach a state we never came across).

if it helps, the commit that changed this file should be 8e914aa

unfortunately, i am no longer maintaining this project.

if you are clever, you may be able to trick @timnewsham into doing so.

best,
-jh