Bug#733551: Sanitation of CPU-state when switching from virtual-8086 mode to other task incomplete
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, if kernel memory layout is known from
System.map, privilege escalation might be quite likely.
* I've not yet tried to build a 64-bit version, but since vm86-syscall
is not required any more, there could be problems there also.
You can find the new improved test code without virtual-8086 mode here:
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
Reply to: