-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 H. Peter Anvin wrote: > On 12/31/2013 11:21 AM, Konrad Rzeszutek Wilk wrote: >> >> So, I am wondering if this is related to " x86/fpu: CR0.TS should >> be set before trap into PV guest's #NM exception handle" which >> does have a similar pattern - you do enough of the task switches >> and the FPU is screwed. >> >> See >> http://mid.gmane.org/1383720072-6242-1-git-send-email-gaoyang....@taobao.com >> >> >> (I thought there was a thread about this on LKML too but I can't >> find it). > > That would be a bug in Xen, so I guess you're surmising a similar > bug in VirtualBox?
Not sure on that yet, but the whole thing is getting even more funnier, the longer I can play with it. Here is some more information from my latest tests: * Although first observed with virtual-8086 mode, the bug is not specific to virtual-8086 mode, it can be triggered with normal x86 userspace code also, even with better reproducibility. * It seems, that when changing the FPU control word with "fstcw" just before exit of the process, then another process could suffer when doing __do_switch * By having two rogue processes writing data to each other via a socket, time and code-position of OOPS can be influenced. * When deactivating mmap_min_addr, the NULL-dereferences during task-switch are exploitable, but I did not get full ring-0 code execution yet, putting EIP to the NULL-seg seem to have failed, perhaps wrong RPL? Hoping to fix that during next days. You can find the new improved test code at [1]. hd [1] http://www.halfdog.net/Security/2013/Vm86SyscallTaskSwitchKernelPanic/FpuStateTaskSwitchOops.c - -- http://www.halfdog.net/ PGP: 156A AE98 B91F 0114 FE88 2BD8 C459 9386 feed a bee -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAlLHQrwACgkQxFmThv7tq+4C+wCfZ0a0LhaJqI7DW78ZFGbnzIyu 6H8AnROrUklhvdbAGV5+7/ELEzPikU7T =jKjH -----END PGP SIGNATURE----- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/