Kernel Panic on user_unblock_thread Syscall

[thosewhowork]

Hello,

I've noticed that invoking the user_unblock_thread syscall (via _kern_unblock_thread in libroot.so) can cause a kernel panic for certain thread_id and status values.

In this specific case, it happened when invoking it for a thread_id belonging to the launch daemon. The status passed was non-zero and matched the thread_id. It is also reproducible for other daemons.

After looking at the disassembly of the kernel, it looks like the exact source line that it's happening on is here: ​https://github.com/haiku/haiku/blob/r1beta2/src/system/kernel/thread.cpp#L2984

System Details

Haiku Version: Haiku R1/Beta2

Guest Machine: VMWare Fusion 8.5.3

Host Machine: Mac OS Mojave

I've attached the backtrace and thread details from the kernel debugger.

Thank you for your hard work and please let me know if I can provide any other details.

[thosewhowork]

Backtrace screenshot

[thosewhowork]

Thread details screenshot

[waddlesplash]

CC'ing korli: I've always wondered if we should not be using set/clear_ac but always go through user_memcpy (I am pretty sure PulkoMandy implied we would have to for SPARC, and possibly other architectures anyway?). It seems strange that the user_thread pointer is incorrect here, but user_memcpy should solve the problem either way.

It also looks like _user_unblock_thread does not actually call thread_check_permissions, either. Wonder how I missed that one.

[korli]

proposed change: ​https://review.haiku-os.org/c/haiku/+/3613

This is without calling thread_check_permissions. The test program isn't made available, so i didn't really invest more time.

[thosewhowork]

Hi Korli,

My bad, here's a hacky test program that should reproduce the bug by brute forcing thread ids:

#include <dlfcn.h>

typedef signed int (*syscall_kern_unblock_thread)(int, int);

int
main(int argc, char** argv) {
    int i = 0;
    syscall_kern_unblock_thread p_kern_unblock_thread = NULL;

    if ((p_kern_unblock_thread = dlsym(RTLD_DEFAULT, "_kern_unblock_thread")) == NULL) {
        return 1;
    }
    
    for (; i < 20000; i++) {
        p_kern_unblock_thread(i, i);
    }

    return 0;
}

Compiled with:

gcc -Wall -o unblock_thread_syscall src/unblock_thread_syscall.c

[X512]

Maybe it is caused by finished thread that is still present for getting exit value (wait_for_thread)?

[waddlesplash]

Fixed in hrev54863. Thanks for reporting -- it looks like you are doing some sort of fuzz testing, right? Do keep us posted on whatever else you find, looks like interesting work :)

[X512]

Is a root cause really fixed?