New Kernel Crash-Exploit discovered

[Michal Jaegermann]

On Mon, Jun 14, 2004 at 10:06:36AM -0700, Villalovos, John L wrote:
> Not sure if people have seen this.

Most likely.  If you want to get technical that is neither an
exploit or crash but you can throw 2.4 and 2.6 kernels into an
infinite FPU exception loop on x86 and x86_64 architectures.  Bad
enough, obviously, but "local" and denial-of-service and not a
security risk.  LARTing should be pretty effective as a short term
paliative if you will run into lusers having a questionable fun.

> I'm assuming that a patch will need
> to be figured out and done.

Last time I looked there was not yet a clear agreement how to fix
that without causing other undesirable side effects.  Anyway, this
should do the job (nearly always?) so you can patch what you run
currently if you are in a hurry.  This is x86 for now and for 2.4.x
this will be similar.


Signed-Off-By: Sergey Vlasov <vsu at altlinux.ru>

--- linux-2.6.6/include/asm-i386/i387.h.fp-lockup	2004-05-10 06:33:06 +0400
+++ linux-2.6.6/include/asm-i386/i387.h	2004-06-12 22:02:58 +0400
@@ -48,10 +48,17 @@
 		save_init_fpu( tsk ); \
 } while (0)
 
+/*
+ * There might be some pending exceptions in the FP state at this point.
+ * However, it is too late to report them: this code is called during execve()
+ * (when the original executable is already gone) and during sigreturn() (when
+ * the signal handler context is already lost).  So just clear them to prevent
+ * problems later.
+ */
 #define __clear_fpu( tsk )					\
 do {								\
 	if ((tsk)->thread_info->status & TS_USEDFPU) {		\
-		asm volatile("fwait");				\
+		asm volatile("fnclex");				\
 		(tsk)->thread_info->status &= ~TS_USEDFPU;	\
 		stts();						\
 	}							\

  Michal