>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 -> -- fedora-legacy-list@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-legacy-list
