Messages in this thread Patch in this message | | | Date | Tue, 22 Mar 2005 20:32:56 +0100 | From | Bodo Stroesser <> | Subject | S390: 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; } | |