This is an automated cleanup. This bug report has been moved to QEMU's new bug tracker on gitlab.com and thus gets marked as 'expired' now. Please continue with the discussion here:
https://gitlab.com/qemu-project/qemu/-/issues/265 ** Changed in: qemu Status: New => Expired ** Bug watch added: gitlab.com/qemu-project/qemu/-/issues #265 https://gitlab.com/qemu-project/qemu/-/issues/265 -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1824344 Title: x86: retf or iret pagefault sets wrong error code Status in QEMU: Expired Bug description: With a x86_64 or i386 guest, non-KVM, when trying to execute a "iret/iretq/retf" instruction in userspace with invalid stack pointer (under a protected mode OS, like Linux), wrong bits are set in the pushed error code; bit 2 is not set, indicating the error comes from kernel space. If the guest OS is using this flag to decide whether this was a kernel or user page fault, it will mistakenly decide a kernel has irrecoverably faulted, possibly causing guest OS panic. How to reproduce the problem a guest (non-KVM) Linux: Note, on recent Linux kernel version, this needs a CPU with SMAP support (eg. -cpu max) $ cat tst.c int main() { __asm__ volatile ( "mov $0,%esp\n" "retf" ); return 0; } $ gcc tst.c $ ./a.out Killed "dmesg" shows the kernel has in fact triggered a "BUG: unable to handle kernel NULL pointer dereference...", but it has "recovered" by killing the faulting process (see attached screenshot). Using self-compiled qemu from git: commit 532cc6da74ec25b5ba6893b5757c977d54582949 (HEAD -> master, tag: v4.0.0-rc3, origin/master, origin/HEAD) Author: Peter Maydell <peter.mayd...@linaro.org> Date: Wed Apr 10 15:38:59 2019 +0100 Update version for v4.0.0-rc3 release Signed-off-by: Peter Maydell <peter.mayd...@linaro.org> To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1824344/+subscriptions
