This is a note to let you know that I've just added the patch titled
signal/sparc32: Exit with a fatal signal when try_to_clear_window_buffer fails
to the 5.15-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
signal-sparc32-exit-with-a-fatal-signal-when-try_to_clear_window_buffer-fails.patch
and it can be found in the queue-5.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@xxxxxxxxxxxxxxx> know about it.
>From c317d306d55079525c9610267fdaf3a8a6d2f08b Mon Sep 17 00:00:00 2001
From: "Eric W. Biederman" <ebiederm@xxxxxxxxxxxx>
Date: Wed, 20 Oct 2021 12:44:01 -0500
Subject: signal/sparc32: Exit with a fatal signal when try_to_clear_window_buffer fails
From: Eric W. Biederman <ebiederm@xxxxxxxxxxxx>
commit c317d306d55079525c9610267fdaf3a8a6d2f08b upstream.
The function try_to_clear_window_buffer is only called from
rtrap_32.c. After it is called the signal pending state is retested,
and signals are handled if TIF_SIGPENDING is set. This allows
try_to_clear_window_buffer to call force_fatal_signal and then rely on
the signal being delivered to kill the process, without any danger of
returning to userspace, or otherwise using possible corrupt state on
failure.
The functional difference between force_fatal_sig and do_exit is that
do_exit will only terminate a single thread, and will never trigger a
core-dump. A multi-threaded program for which a single thread
terminates unexpectedly is hard to reason about. Calling force_fatal_sig
does not give userspace a chance to catch the signal, but otherwise
is an ordinary fatal signal exit, and it will trigger a coredump
of the offending process if core dumps are enabled.
Cc: David Miller <davem@xxxxxxxxxxxxx>
Cc: sparclinux@xxxxxxxxxxxxxxx
Link: https://lkml.kernel.org/r/20211020174406.17889-15-ebiederm@xxxxxxxxxxxx
Signed-off-by: Eric W. Biederman <ebiederm@xxxxxxxxxxxx>
Cc: Thomas Backlund <tmb@xxxxxx>
Signed-off-by: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
---
arch/sparc/kernel/windows.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
--- a/arch/sparc/kernel/windows.c
+++ b/arch/sparc/kernel/windows.c
@@ -121,8 +121,10 @@ void try_to_clear_window_buffer(struct p
if ((sp & 7) ||
copy_to_user((char __user *) sp, &tp->reg_window[window],
- sizeof(struct reg_window32)))
- do_exit(SIGILL);
+ sizeof(struct reg_window32))) {
+ force_fatal_sig(SIGILL);
+ return;
+ }
}
tp->w_saved = 0;
}
Patches currently in stable-queue which might be from ebiederm@xxxxxxxxxxxx are
queue-5.15/signal-vm86_32-properly-send-sigsegv-when-the-vm86-state-cannot-be-saved.patch
queue-5.15/signal-don-t-always-set-sa_immutable-for-forced-signals.patch
queue-5.15/signal-x86-in-emulate_vsyscall-force-a-signal-instead-of-calling-do_exit.patch
queue-5.15/ipc-warn-if-trying-to-remove-ipc-object-which-is-absent.patch
queue-5.15/signal-replace-force_sigsegv-sigsegv-with-force_fatal_sig-sigsegv.patch
queue-5.15/signal-powerpc-on-swapcontext-failure-force-sigsegv.patch
queue-5.15/exit-syscall_user_dispatch-send-ordinary-signals-on-failure.patch
queue-5.15/signal-s390-use-force_sigsegv-in-default_trap_handler.patch
queue-5.15/signal-implement-force_fatal_sig.patch
queue-5.15/signal-sparc32-in-setup_rt_frame-and-setup_fram-use-force_fatal_sig.patch
queue-5.15/signal-sparc32-exit-with-a-fatal-signal-when-try_to_clear_window_buffer-fails.patch
queue-5.15/shm-extend-forced-shm-destroy-to-support-objects-from-several-ipc-nses.patch
queue-5.15/signal-replace-force_fatal_sig-with-force_exit_sig-when-in-doubt.patch
