Public bug reported:
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>
** Affects: qemu
Importance: Undecided
Status: New
** Tags: amd64 i386
** Attachment added: "dmesg screenshot"
https://bugs.launchpad.net/bugs/1824344/+attachment/5254916/+files/dmesg.png
--
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:
New
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
