On Wed, Jul 30, 2014 at 07:34:47PM +0200, Ralf Baechle wrote:
> On Tue, Jul 22, 2014 at 02:21:21PM +0100, Paul Burton 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.
>
> Ralf
Any chance you could expand that acronym for me? Maybe I'm being slow
since neither of the expansions that spring to mind make much sense.
Thanks,
Paul
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
