SOURCES: signal.c-2.4.26.patch (NEW) - [SECURITY] http://linuxrevi...

[Jakub Bogusz]

On Tue, Jun 15, 2004 at 11:32:25AM +0200, Jakub Bogusz wrote:
> On Tue, Jun 15, 2004 at 06:22:48AM +0000, paszczus wrote:
> > diff -u /dev/null SOURCES/signal.c-2.4.26.patch:1.1
> > --- /dev/null	Tue Jun 15 06:22:48 2004
> > +++ SOURCES/signal.c-2.4.26.patch	Tue Jun 15 06:22:42 2004
> > @@ -0,0 +1,19 @@
> > +--- linux-2.4.26/kernel/signal.c	2004-02-18 14:36:32.000000000 +0100
> > ++++ linux-2.4.26-x/kernel/signal.c	2004-06-13 12:21:12.000000000 +0200
> > +@@ -568,8 +568,14 @@
> > + 	   can get more detailed information about the cause of
> > + 	   the signal. */
> > + 	if (sig < SIGRTMIN && sigismember(&t->pending.signal, sig))
> > +-		goto out;
> > +-
> > ++	{
> > ++		if (sig==8)
> > ++		{
> > ++		printk("Attempt to exploit known bug, process=%s  pid=%d uid=%d\n", t->comm, t->pid, t->uid);
> > ++		do_exit(0);
> > ++		}	
> > ++	goto out;
> > ++	}
> > + 	ret = deliver_signal(sig, info, t);
> > + out:
> > + 	spin_unlock_irqrestore(&t->sigmask_lock, flags);
> 
> Co to, skąd to?
> Bo właściwa poprawka (pod URL-em z komentarza) wygląda inaczej.

A dokładniej tak:
http://linuxreviews.org/news/2004-06-11_kernel_crash/24_kernel_ia32-and-x86_64-fix-fpu-state.patch.txt

natomiast powyższe wygląda brzydko (użycie 8 zamiast SIGFPE) i bardziej
na workaround niż poprawkę.


-- 
Jakub Bogusz    http://cyber.cs.net.pl/~qboosh/