blob: d3ac6c0d127871a690b49105e082773737590f55 (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
|
<think>
Okay, so I'm trying to classify this bug report related to QEMU. The issue is that when setreuid() or setegid() are called from x86_64 user-mode target code in QEMU, it crashes inside the NPTL signal handlers.
From the description, it seems like the problem arises because the x86 targets don't directly use a syscall for these functions. Instead, they use a temporary memory region __xidcmd and send a SIGRT1 signal to all threads. However, in QEMU, this __xidcmd remains null, causing issues.
Looking at the backtrace, it shows that the crash happens in the sighandler_setxid function when trying to access __xidcmd, which is null. This leads me to think that the problem is related to how these syscalls are being handled within QEMU's user-mode environment.
The categories given are instruction, syscall, and runtime. Since the issue revolves around the handling of setreuid/setegid syscalls and their implementation in the NPTL threading model under QEMU, it seems like a problem with how the system calls are processed or emulated. Therefore, I think this falls under the 'syscall' category.
</think>
syscall
|