Re: [PATCH 10/20] signal/vm86_32: Properly send SIGSEGV when the vm86 state cannot be saved.
From: "Andy Lutomirski" <luto@kernel.org>
Date: 2021-10-21 23:09:29
Also in:
lkml
On Wed, Oct 20, 2021, at 10:43 AM, Eric W. Biederman wrote:
Instead of pretending to send SIGSEGV by calling do_exit(SIGSEGV) call force_sigsegv(SIGSEGV) to force the process to take a SIGSEGV and terminate.
Why? I realize it's more polite, but is this useful enough to justify the need for testing and potential security impacts?
Update handle_signal to return immediately when save_v86_state fails and kills the process. Returning immediately without doing anything except killing the process with SIGSEGV is also what signal_setup_done does when setup_rt_frame fails. Plus it is always ok to return immediately without delivering a signal to a userspace handler when a fatal signal has killed the current process.
I can mostly understand the individual sentences, but I don't understand what you're getting it. If a fatal signal has killed the current process and we are guaranteed not to hit the exit-to-usermode path, then, sure, it's safe to return unless we're worried that the core dump code will explode. But, unless it's fixed elsewhere in your series, force_sigsegv() is itself quite racy, or at least looks racy -- it can race against another thread calling sigaction() and changing the action to something other than SIG_DFL. So it does not appear to actually reliably kill the caller, especially if exposed to a malicious user program.
quoted hunk ↗ jump to hunk
Cc: Thomas Gleixner <redacted> Cc: Ingo Molnar <mingo@redhat.com> Cc: Borislav Petkov <bp@alien8.de> Cc: x86@kernel.org Cc: H Peter Anvin <hpa@zytor.com> Signed-off-by: "Eric W. Biederman" <redacted> --- arch/x86/kernel/signal.c | 6 +++++- arch/x86/kernel/vm86_32.c | 2 +- 2 files changed, 6 insertions(+), 2 deletions(-)diff --git a/arch/x86/kernel/signal.c b/arch/x86/kernel/signal.c index f4d21e470083..25a230f705c1 100644 --- a/arch/x86/kernel/signal.c +++ b/arch/x86/kernel/signal.c@@ -785,8 +785,12 @@ handle_signal(struct ksignal *ksig, struct pt_regs *regs) bool stepping, failed; struct fpu *fpu = ¤t->thread.fpu; - if (v8086_mode(regs)) + if (v8086_mode(regs)) { save_v86_state((struct kernel_vm86_regs *) regs, VM86_SIGNAL); + /* Has save_v86_state failed and killed the process? */ + if (fatal_signal_pending(current)) + return;
This might be an ABI break, or at least it could be if anyone cared about vm86. Imagine this wasn't guarded by if (v8086_mode) and was just if (fatal_signal_pending(current)) return; Then all the other processing gets skipped if a fatal signal is pending (e.g. from a concurrent kill), which could cause visible oddities in a core dump, I think. Maybe it's minor.
quoted hunk ↗ jump to hunk
+ } /* Are we from a system call? */ if (syscall_get_nr(current, regs) != -1) {diff --git a/arch/x86/kernel/vm86_32.c b/arch/x86/kernel/vm86_32.c index 63486da77272..040fd01be8b3 100644 --- a/arch/x86/kernel/vm86_32.c +++ b/arch/x86/kernel/vm86_32.c@@ -159,7 +159,7 @@ void save_v86_state(struct kernel_vm86_regs *regs,int retval) user_access_end(); Efault: pr_alert("could not access userspace vm86 info\n"); - do_exit(SIGSEGV); + force_sigsegv(SIGSEGV);
This causes us to run unwitting kernel code with the vm86 garbage still loaded into the relevant architectural areas (see the chunk if save_v86_state that's inside preempt_disable()). So NAK, especially since the aforementioned race might cause the exit-to-usermode path to actually run with who-knows-what consequences. If you really want to make this change, please arrange for save_v86_state() to switch out of vm86 mode *before* anything that might fail so that it's guaranteed to at least put the task in a sane state. And write an explicit test case that tests it. I could help with the latter if you do the former. --Andy