On Wed, 30 Jul 2014, Ralf Baechle wrote: > > If one or more matching FCSR cause & enable bits are set in saved thread > > context then when that context is restored the kernel will take an FP > > exception. This is of course undesirable and considered an oops, leading > > to the kernel writing a backtrace to the console and potentially > > rebooting depending upon the configuration. Thus the kernel avoids this > > situation by clearing the cause bits of the FCSR register when handling > > FP exceptions and after emulating FP instructions. > > > > However the kernel does not prevent userland from setting arbitrary FCSR > > cause & enable bits via ptrace, using either the PTRACE_POKEUSR or > > PTRACE_SETFPREGS requests. This means userland can trivially cause the > > kernel to oops on any system with an FPU. Prevent this from happening > > by clearing the cause bits when writing to the saved FCSR context via > > ptrace. > > > > This problem appears to exist at least back to the beginning of the git > > era in the PTRACE_POKEUSR case. > > Good catch - but I think something like UML on a more proper fix. How > until then I'm going to apply this. I'm not sure what you mean by UML, but this is definitely a valid action, you need to be able to do anything from GDB that a program can do itself, and a program can raise FP exceptions to itself by fiddling with CP1.FCSR; this is even required by the ISO C language standard (see the pieces in <fenv.h>). So I think the kernel should be prepared to handle such exceptions on context switches; and also emulate them if no FP hardware is used. I suspect a similar condition exists when a program writes to the saved image of CP1.FCSR in a signal handler and then restores that context. I don't know offhand if this is supported by any standard though; intuitively it should. Maciej -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html