Re: [PATCH 1/3] signal(i386): alternative signal stack wraparound occurs

[Shi Weihua <shiwh@cn.fujitsu.com>]

Roland McGrath wrote::
>>> Thank you for your detailed explanation and patch. I tested your 
>>> patch, unfortunately it can not stop all kinds of overflow.
>> [...]
>>> So, the patch I posted is still needed 
>> thanks, i've picked up your fix for x86.git, for 2.6.25 merging.
> 
> I just explained that not all overflows would be caught and that doing so
> would violate the semantics of e.g. longjmp.  I don't see how the patch
> you've included now doesn't still have all those problems.  I think it's wrong.
> 

I am sorry, i don't understand how this is related to the semantics of e.g. longjmp.
But, i am sure my patch solves all overflows. Ingo's patch can't catch the overflow 
which is caught by "int i[1000];" in the handler function.

Do you have more idea for me? Thanks.

Regards
Shi Weihua

By the way, I think Ingo's patch can be improved. 

Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Shi Weihua <shiwh@cn.fujitsu.com>

---
--- linux-2.6.24-rc4-git1.orig/arch/x86/kernel/signal_32.c	2007-12-04 12:26:10.000000000 +0800
+++ linux-2.6.24-rc4-git1/arch/x86/kernel/signal_32.c	2007-12-05 11:13:56.000000000 +0800
@@ -297,8 +297,17 @@ get_sigframe(struct k_sigaction *ka, str
 
 	/* This is the X/Open sanctioned signal stack switching.  */
 	if (ka->sa.sa_flags & SA_ONSTACK) {
-		if (sas_ss_flags(esp) == 0)
+		int onstack = sas_ss_flags(esp);
+		if (onstack == 0)
 			esp = current->sas_ss_sp + current->sas_ss_size;
+		else if(onstack == SS_ONSTACK){
+			/*
+			 * If we are on the alternate signal stack and would overflow it, don't.
+			 * Return an always-bogus address instead so we will die with SIGSEGV.
+			 */
+			if (!likely(on_sig_stack(esp - frame_size)))
+				return (void __user *) -1L;
+		}
 	}
 
 	/* This is the legacy signal stack switching. */


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/