lkml.org 
[lkml]   [2005]   [Mar]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
Date
From
SubjectS390: bug in signal frame set up when using SA_ONSTACK
Hi

IMHO, there is a bug in s390's signal frame handling:

If a signal handler is set to use the signal stack (SA_ONSTACK), but
the signal stack is disabled, the signal frame should be written to
the current stack without stack switching.
S390 doesn't note, that the signal stack is disabled, so it does
stack switching to a stack at 0, size 0. Then it writes the signal frame
to "0x00000000 - sizeof(sigframe)".
If a further signal comes in, while the handler is running, the next
signal frame even will overwrite the previous one.

The reason for the bug is get_sigframe() using on_sig_stack() instead
of sas_ss_flags(), which would be ok. (Oneliner patch attached)

AFAICS, the problem is in 2.4 and 2.6 kernels.

If the error occurs, bit 0 of stack pointer gpr15 is set. In
arch/s390/kernel/signal.c, there is no masking of gpr15 before passing
it to do_sigaltstack() or on_sig_stack()/sas_ss_flags(). Wouldn't it
be better to reset bit 0, to avoid possible problems?

Please CC me, I'm not on the list.

Bodo

--- a/arch/s390/kernel/signal.c 2005-03-22 11:07:39.000000000 +0100
+++ b/arch/s390/kernel/signal.c 2005-03-22 11:08:44.000000000 +0100
@@ -285,7 +285,7 @@

/* This is the X/Open sanctioned signal stack switching. */
if (ka->sa.sa_flags & SA_ONSTACK) {
- if (! on_sig_stack(sp))
+ if (! sas_ss_flags(sp))
sp = current->sas_ss_sp + current->sas_ss_size;
}
\
 
 \ /
  Last update: 2005-04-06 13:30    [W:0.030 / U:0.020 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site