On Fri, 2014-01-03 at 23:20 +0000, halfdog wrote: > 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. This is why no-one sets mmap_min_addr to 0 any more... > * 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 I commented-out the mmap-ing as I just want to see the oops rather than work out how exploitable it might be. But I didn't get an oops when running on either the -486 or -686-pae kernel flavour, in a VM on an Intel or AMD 64-bit CPU, or directly on an Intel 64-bit CPU. (The AMD system is a server I don't want to take down.) Can you confirm that you are able to reproduce this without a VM, and send the contents of /proc/cpuinfo on the affected system(s)? Ben. -- Ben Hutchings Any smoothly functioning technology is indistinguishable from a rigged demo.
Attachment:
signature.asc
Description: This is a digitally signed message part