New Kernel Crash-Exploit discovered

[Simon Weller]

>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.

Linus appears to have now approved a patch:

http://linux.bkbits.net:8080/linux-2.4/gnupatch%4040cdf6f8V7sOe5n96HA5Q7r9uDRvJQ

It's supposedly compatible with 2.4.2x

This is the same patch as posted by Dave Jones, but just the x86 patch.

- Si

>
>
>Signed-Off-By: Sergey Vlasov <vsu 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
-- 
Simon Weller LPIC-2, BCIP
Systems Engineer
NZServers LTD
http://www.nzservers.com/
U.S. Branch

<-
To mess up a Linux box, you need to work at it; to mess up your Windows box, 
you just need to work on it.
 - Scott Granneman, Security Focus
->